亿级流量、高并发与高性能场景下的电商详情页架构_9(哨兵节点的管理，以及高可用Redis集群的容灾演练)

亿级流量、高并发与高性能场景下的电商详情页架构_9(哨兵节点的管理，以及高可用Redis集群的容灾演练)

1：哨兵节点的增加和删除

• 增加 ：增加sentinel的时候，会自动发现，具体上一节中有提到
• 删除：

删除的步骤
1：停止sentinel进程
2：SENTINEL RESET *，在所有sentinel执行，清理所有的master状态
3：SENTINEL MASTER mastername，在所有的sentinel上执行，查看所有的sentinel对数量是否达成一致

2：slave的永久下线

让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行

容灾演练

杀掉master节点中的进程模拟故障发生

+sdown master mymaster 192.168.1.110 6379
当前节点超过 sentinel down-after-milliseconds mymaster 30000，ping不通，这是就认为当前 192.168.1.110 6379 sdown了
+odown master mymaster 192.168.1.110 6379 #quorum 3/2
超过了 quorum个 节点认为 sdown 这个时候，转换为了odown
+new-epoch 1
获得版本号，并且加1
+try-failover master mymaster 192.168.1.110 6379
对 192.168.1.110 6379 进行故障切换
+vote-for-leader 86e40dddb954a99cb246959eeb9b8d982736d469 1
48c1f55d16d663fb62c6bc4b47931efc2db3c534 voted for86e40dddb954a99cb246959eeb9b8d982736d469 1
0e0fd5cfc1903e27ac3433d88ea3b77e53ec7740 voted for 0e0fd5cfc1903e27ac3433d88ea3b77e53ec7740 1
进行选举，选出一个sentinel节点,
+elected-leader master mymaster 192.168.1.110 6379
在哨兵集群中再次确认进行故障转移的leader是哪一个slave。
+failover-state-select-slave master mymaster 192.168.1.110 6379
leader开始在集群中寻找合适的slave。(从这里可以看出，找出新的slave不单单是通过投票，可能还和其它的因素有关。)
+selected-slave slave 192.168.1.111:6379 192.168.1.111 6379 @ mymaster 192.168.1.110 6379
出现"+selected-slave"意味着已经找到了合适的slave作为新的master，它是位于S2服务器上的192.168.50.122 6379 Redis服务
+failover-state-send-slaveof-noone slave 192.168.1.111:6379 192.168.1.111 6379 @ mymaster 192.168.1.110 6379
Leader向目标slave发送"slaveof-noone"指令，令其不要再做其它任何节点的slave了，从现在开始，它就是老大，完成从slave到master的转换。
+failover-state-wait-promotion slave 192.168.1.111:6379 192.168.1.111 6379 @ mymaster 192.168.1.110 6379
等待其它的sentinel确认slave
+promoted-slave slave 192.168.1.111:6379 192.168.1.111 6379 @ mymaster 192.168.1.110 6379
开始对集群中的所有slave做reconf操作(更新配置信息)。
+failover-state-reconf-slaves master mymaster 192.168.1.110 6379
向指定的slave发送"slaveof"指令，令其跟随新的master。
+failover-end master mymaster 192.168.1.110 6379
本次故障转移完毕。。
+switch-master mymaster 192.168.1.110 6379 192.168.1.111 6379
故障转移完毕后，各个sentinel开始监控新的master。
这句话执行完毕后，我们可以去哨兵的配置文件中看到，sentinel monitor mymaster后面的ip已经发生了变化。
+slave slave 192.168.1.110:6379 192.168.1.110 6379 @ mymaster 192.168.1.111 6379

连上哨兵查看master的地址，发现已经改变了

查看新的master，发现master节点下面没有挂载slave，这是因为，之前的那个已经关掉了，还没有进行故障修复

重启后发现

已经有了