sentinel监控redis高可用集群(一)

时间:2024-01-18 08:41:26
一、首先配置redis的主从同步集群。
1、主库的配置文件不用修改,从库的配置文件只需增加一行,说明主库的IP端口。如果需要验证的,也要加多一行,认证密码。
slaveof 192.168.20.26 5268
masterauth hodge01
sentinel监控redis高可用集群(一)
一主多从的话,就启用多个从库。其中,从库都是一样的方案。本次有两个slave。
2、命令检查。
/usr/local/redis/bin/redis-cli -p 5257 -a hodge01 info Replication
sentinel监控redis高可用集群(一)
二、sentinel高可用。
1、概况。sentinel是redis自带的附件,在新的版本redis安装都有sentinel。sentinel是称作哨兵的监控机制,当达到一定数量的sentinel投票支持,redis的master就会切换。本次使用docker容器搭建,主要讲述配置文件。
2、配置文件。注意:每次要抛弃上一次集群都考检查配置文件,因为sentinel是靠更改配置文件实现功能的。
sentinel监控redis高可用集群(一)
监听端口。
sentinel监控redis高可用集群(一)
第一行最后的那个2,是说明需要两个sentinel确认客观下线,需要切换,才能操作。
sentinel监控redis高可用集群(一)
如果有需要密码验证的,要在这里添加密码信息,否则不能通讯。
在配置文件后面几行是启动后系统自动添加。
sentinel监控redis高可用集群(一)
3、启动。
启动之后,本实验就是3台redis,三台sentinel,sentinel的配置文件自动填写了sentinel集群和redis集群的信息。因为网络影响,所以单单凭一台sentinel之言就随便切换,所以一般情况需要3台sentinel以上。
确认5268是master,连接两个slave。
sentinel监控redis高可用集群(一)
4、测试。
a、关掉5268redis。
sentinel监控redis高可用集群(一)
b、检查4157和5257redis。发现master已经转移到5257。
sentinel监控redis高可用集群(一)
c、查看转移日志。
+failover-state-reconf-slaves master mymaster
…………
+failover-end master mymaster
sentinel监控redis高可用集群(一)
第一行是确认预先的架构复核标准。
第二行认为5268已经客观下线。
第三行表示准备重写主从架构的配置文件。
第四行表示开始重写。
第五行表示故障切换处理5268完毕.。
第六、七行记录在sentinel中已经认为4157和5268作为slave已经追随5257master。
第九行sentinel认为5268已经沦落为slave,但是并不在线。紧接着标记主观下线。
第十行表示5268重启后符合slave标准,用“-”移除主观下线记录。
但是,查了两次5257,并没有发现5268的信息。于是我们查看redis5258的日志,看没有连上master是怎么回事,反正sentinel那边已经认为连上。
sentinel监控redis高可用集群(一)
d、恢复后的redis5268的日志。(异常处理)
NOAUTH Authentication required.
sentinel监控redis高可用集群(一)
满满的认证不成功,已经很明显告知,5268恢复之后就是slave了,因为此时的5257已经有了密码,而5268没有密码记录,自然没有认证成功连上master5257。
所以在redis5268加上在master面前的认证密码。
masterauth hodge01
sentinel监控redis高可用集群(一)
e、重启验证。
重启redis5268
sentinel监控redis高可用集群(一)
检查redis master5257,发现5268已经连上。
到此为止,sentinel支持的redis高可用集群就全部完成,IP自动切换方面下次探索。