redis高可用-哨兵机制

一:背景

上一节我们已经实现了redis的主从同步,从而实现服务的流量分摊和数据高可用,但是出现故障以后,需要人工手动接入,手动切换主从,来实现故障转移。这是比较麻烦的,毕竟人不能实时盯着服务,如果没有人工介入,如何实现redis高可用呢?还好redis设计者帮我们考虑了解决方案,可以使用哨兵机制。

二:配置实现

1:环境介绍:

主redis服务: ip 192.168.56.101

从1: ip 192.168.56.102

从2: ip 192.168.56.103

2:前提条件(主从同步需要提前配置好):

主服务配置:

masterauth "123456"

从1配置:

masterauth "123456"

replicaof 192.168.56.101 6379

从2配置:

masterauth "123456"

replicaof 192.168.56.101 6379

3:配置哨兵

我们直接在主服务所在服务器上部署哨兵,也可以在每台服务器上单独部署一个哨兵,这里要至少部署三个哨兵。

从redis安装包的src目录复制哨兵启动文件:

mkdir /usr/local/sentinel/

cp /usr/local/redis/redis-6.0.7/src/redis-sentinel /usr/local/sentinel/

创建三份哨兵配置文件,这里监听的端口为5000-5002

vi s1/sentinel_5000.conf

sentinel deny-scripts-reconfig yes //不允许使用SENTINEL SET设置

sentinel monitor mymaster 192.168.56.101 6379 2 //自定义主节点名称

sentinel auth-pass mymaster 123456

sentinel failover-timeout mymaster 18000 //故障中每个阶段的最长超时时间

daemonize yes

port 5000 //哨兵端口号

logfile "/usr/local/sentinel/s1/sentinel.log"

dir "/usr/local/sentinel/s1/data"

复制以上文件,只需要修改端口号,logfile和dir即可

复制的目录为

s2/sentinel_5001.conf

s3/sentinel_5002.conf

启动哨兵:

#!/bin/bash

./redis-sentinel ./s1/sentinel_5000.conf

./redis-sentinel ./s2/sentinel_5001.conf

./redis-sentinel ./s3/sentinel_5002.conf

4:故障自动转移实测

现在我们的主节点是192.168.56.101

我们查看 我们的哨兵日志

发现主节点的确是192.168.56.101

我们把主节点关闭redis服务,哨兵会工作去重新选举一个节点作为主节点,我们试下

关闭服务以后,我们查看哨兵日志

发现主服务从192.168.56.101这台机器变更为192.168.56.103这台机器。

我们在103这台机器的redis上写入数据。

发现103可以写入数据,同时102的服务已经同步了数据了,这时候我们重新打开101的redis服务

发现101这台机器的redis也从103同步了数据。

通过以上的操作,我们发现101主服务出现故障以后,哨兵检测到故障从从服务中的两个102和103中选择了103作为新的主服务,继续工作。

三:总结

redis哨兵机制,可以在主服务挂掉接口,快速的从服务中选举新的服务作为主服务继续提供服务。从而实现故障自动修复。让redis高可用更加稳固。

相关推荐
先吃饱再说16 小时前
存储的进化:从 MySQL 到浏览器缓存,数据到底住在哪?
数据库
Nturmoils16 小时前
字段太多看不全,ksql 的展开模式和输出控制怎么用
数据库·后端
Databend19 小时前
Agent 轨迹分析与归因的数据工程实践
大数据·数据库·agent
这个DBA有点耶19 小时前
SQL改写进阶:标量子查询的“隐形代价”与消除实战
数据库·mysql·架构
smallyoung20 小时前
数据库乐观锁深度解析:MySQL、PostgreSQL 实战 + Spring Boot 集成指南
数据库·mysql·postgresql
parade岁月20 小时前
MySQL JOIN解析:朴实无华但食之有味
数据库·后端
用户31693538118321 小时前
MySQL服务无法启动问题解决全记录
数据库
vivo互联网技术1 天前
从 10 分钟到 1 秒:ES 深度分页任意跳页的三轮优化实战
服务器·数据库·redis·elasticsearch·深度分页
倔强的石头_2 天前
《Kingbase护城河》——猎捕慢查询:执行计划的微观解析与索引调优实战
数据库