sentinel监控redis高可用集群（一）

一、首先配置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自动切换方面下次探索。