Redis哨兵模式（故障转移测试）
最新回答
你活该阿
2020-09-10 13:57:51
问题：如果哨兵集群也有部分实例down了，出现偶数哨兵，或者只剩下一个哨兵会如何，还能进行故障转移吗。
为什么会出现这个问题：哨兵其实也是redis实例，一般情况下，哨兵是为了保证redis集群的故障转移。由于资源，以及网络通信的性能考虑，一般哨兵和redis会部署在同一物理机。如果一台物理机出现了物理故障，哨兵实例和redis服务实例会一起down掉。
本文章针对这个问题做一下实验。
使用3+3模式，3redis+3sentinel。
三台虚拟机，每台虚拟机运行1个redis+1个sentinel
ip、角色规划
192.168.237.101：master，sentinel
192.168.237.100：slave，sentinel
192.168.237.103：slave，sentinel
安装redis、redis sentinel
apt-get install redis-server
apt-get install redis-sentinel
redis-server配置修改(/etc/redis/redis.conf)
redis-server slave配置修改
启动redis-server
/etc/init.d/redis-server restart
查看redis-server主从集群情况
修改sentinel配置(/etc/redis/sentinel.conf)
sentinel monitor mymaster 192.168.237.101 6379 2
sentinel known-slave mymaster 192.168.237.100 6379
protected-mode no
启动sentinel
/etc/init.d/redis-sentinel start
查看redis-sentinel情况
预期：故障转移，哨兵选举出新的master
关掉redis-server（192.168.237.101）
查看sentinel日志（/var/log/redis/redis-sentinel.log）
可以看到，+odown master，哨兵检测master客观下线
然后进行投票：vote-for-leader
选出新的master：switch-master mymaster 192.168.237.101 6379 192.168.237.103 6379
192.168.237.101的sentinel日志：
查看redis和sentinel集群状态，确认master变成了192.168.237.103（master host）
恢复192.168.237.101的redis-server，查看日志，192.168.237.101转换成slave
预期：有两个sentinel，可能会出现，剩下两个slave各得一票的情况，按照哨兵原理，会等待一段时间进行再选举，直到某个slave有两票，完成故障转移。
经过3.1实验，master转换到了192.168.237.103，现在先后关掉103上的sentinel和redis-server
查看两台sentinel的redis-sentinel日志，可以选出master，进行故障转移：
查看redis集群状态，确认master（192.168.237.100）
预期：无法切换
依次关掉两个sentinel，一个redis-server master。3.2节master转移到了100，恢复环境后，依次关掉103,100的sentinel，100的redis-server master
查看101上的sentinel日志，由于只有一个sentinel，只有101上的sentinel投票
恢复一个redis-sentinel，现有两个redis-sentinel
查看sentinel日志，选出101为master
有两个sentinel或以上可以进行故障切换。单数sentinel更容易选出master，进行故障转移。
+sdown：主观down机
+odown：客观down机
+new-epoch：集群递增版本号
+vote-for-leader：在哨兵集群中投票选举出一个哨兵，作为本次执行故障转移操作的leader
+try-failover：开始对某ip进行故障转移
voted for：另一个哨兵进行投票
+elected-leader：在哨兵集群中再次确认进行即将执行故障转移的leader是哪一个哨兵。
+selected-slave slave：选出leader
+failover-state-send-slaveof-noone slaveLeader：向目标slave发送"slaveof-noone"指令，令其不要再做其它任何节点的slave了，从现在开始，它就是老大，完成从slave到master的转换。
+failover-state-wait-promotion slave：等待其它的sentinel确认slave
+promoted-slave slave：其它的sentinel全部确认成功
+failover-state-reconf-slaves：开始对集群中的所有slave做reconf操作(更新配置信息)
+slave-reconf-sent：向指定的slave发送"slaveof"指令，令其跟随新的master
+switch-master：故障转移完毕后，各个sentinel开始监控新的master
热门标签
