一、首先配置redis的主从同步集群

1、主库的配置文件不用修改,从库的配置文件只需增加一行,说明主库的IP端口。如果需要验证的,也要加多一行,认证密码。

slaveof 192.168.20.26 5268

masterauth hodge01

一主多从的话,就启用多个从库。其中,从库都是一样的方案。本次有两个slave。

2、命令检查

/usr/local/redis/bin/redis-cli -p 5257 -a hodge01 info Replication

二、sentinel高可用

1、概况。sentinel是redis自带的附件,在新的版本redis安装都有sentinel。sentinel是称作哨兵的监控机制,当达到一定数量的sentinel投票支持,redis的master就会切换。本次使用docker容器搭建,主要讲述配置文件。

2、配置文件。注意:每次要抛弃上一次集群都考检查配置文件,因为sentinel是靠更改配置文件实现功能的。

监听端口。

第一行最后的那个2,是说明需要两个sentinel确认客观下线,需要切换,才能操作。

如果有需要密码验证的,要在这里添加密码信息,否则不能通讯。

在配置文件后面几行是启动后系统自动添加。

3、启动。

启动之后,本实验就是3台redis,三台sentinel,sentinel的配置文件自动填写了sentinel集群和redis集群的信息。因为网络影响,所以单单凭一台sentinel之言就随便切换,所以一般情况需要3台sentinel以上。

确认5268是master,连接两个slave。

4、测试。

a、关掉5268redis。

b、检查4157和5257redis。发现master已经转移到5257。

c、查看转移日志。

+failover-state-reconf-slaves master mymaster

…………

+failover-end master mymaster

第一行是确认预先的架构复核标准。

第二行认为5268已经客观下线。

第三行表示准备重写主从架构的配置文件。

第四行表示开始重写。

第五行表示故障切换处理5268完毕.。

第六、七行记录在sentinel中已经认为4157和5268作为slave已经追随5257master。

第九行sentinel认为5268已经沦落为slave,但是并不在线。紧接着标记主观下线。

第十行表示5268重启后符合slave标准,用“-”移除主观下线记录。

但是,查了两次5257,并没有发现5268的信息。于是我们查看redis5258的日志,看没有连上master是怎么回事,反正sentinel那边已经认为连上。

d、恢复后的redis5268的日志。(异常处理)

NOAUTH Authentication required.

满满的认证不成功,已经很明显告知,5268恢复之后就是slave了,因为此时的5257已经有了密码,而5268没有密码记录,自然没有认证成功连上master5257。

所以在redis5268加上在master面前的认证密码。

masterauth hodge01

e、重启验证。

重启redis5268

检查redis master5257,发现5268已经连上。

到此为止,sentinel支持的redis高可用集群就全部完成,IP自动切换方面下次探索。

以上就是sentinel支持的redis高可用集群配置详解的详细内容,更多关于sentinel redis高可用集群配置的资料请关注脚本之家其它相关文章!

更多文章请关注《万象专栏》