Redis 哨兵模式下，Master节点宕机后，进行故障转移的过程

有三台服务器

S1：192.168.50.121

S2：192.168.50.122

S3：192.168.50.123

其中S1、S2上部署了Redis服务和Redis sentinel，S3上只部署了Redis sentinel。

假设S1是Master，突然宕机，在经过一段时间后(down_after_milliseconds)，可以看到控制台输出如下语句:

1. +sdown master mymaster 192.168.50.121 6379

当前哨兵认为master已经主观宕机，也就是sdown。

2.  +odown master mymaster 192.168.50.121 6379 #quorum 2/2

由于哨兵集群内有超过两个哨兵都认为master sdown了，因此转化成客观宕机，也就是odown。

3.  +new-epoch 1

递增集群状态版本号，这个版本号将被接下来选举出的新的master采用。

从这个可以看出，集群版本号是哨兵创建和维护的。

4. +vote-for-leader 2d271223c7df8d1d54967ee893fbebfbf6c60ab1 1

在哨兵集群中投票选举出一个哨兵，作为本次执行故障转移操作的leader。

5.  +try-failover master mymaster 192.168.50.121 6379

开始对IP为192.168.50.121，端口为6379，名为"mymaster"的Redis集群进行故障转移。

6.  +vote-for-leader 2d271223c7df8d1d54967ee893fbebfbf6c60ab1 1

当前哨兵投票给自己满意的slave

7. 337d50c8ef65a708ad27be2ce1ab9d3552046b64 voted for 2d271223c7df8d1d54967ee893fbebfbf6c60ab1 1

另一个哨兵投票给自己满意的slave

8.  ce1868c3f2dcc412d2348ffa6ccb5e6222ad1a47 voted for 2d271223c7df8d1d54967ee893fbebfbf6c60ab1 1

另一个哨兵投票给自己满意的slave

9.  +elected-leader master mymaster 192.168.50.121 6379

在哨兵集群中再次确认进行即将执行故障转移的leader是哪一个哨兵。 

10. +failover-state-select-slave master mymaster 192.168.50.121 6379

leader开始在集群中寻找合适的slave。(从这里可以看出，找出新的slave不单单是通过投票，可能还和其它的因素有关。)

11.  +selected-slave slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379

出现"+selected-slave"意味着已经找到了合适的slave作为新的master，它是位于S2服务器上的192.168.50.122 6379 Redis服务。

12.  +failover-state-send-slaveof-noone slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379

Leader向目标slave发送"slaveof-noone"指令，令其不要再做其它任何节点的slave了，从现在开始，它就是老大，完成从slave到master的转换。

13. +failover-state-wait-promotion slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379

等待其它的sentinel确认slave

14. +promoted-slave slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379

”+promoted-slave“ 意味着其它的sentinel全部确认成功。

15.  +failover-state-reconf-slaves master mymaster 192.168.50.121 6379

开始对集群中的所有slave做reconf操作(更新配置信息)。

16. +slave-reconf-sent 

向指定的slave发送"slaveof"指令，令其跟随新的master。

17. +slave-reconf-inprog 

目标slave正在执行slaveof操作，如果在此期间，又接收到了新的"slave-reconf-sent"命令，则在会在当前操作执行完毕后，再次执行slaveof。

18. +slave-reconf-done

目标slave配置信息更新完毕，leader可以对下一个slave开始reconfig操作了。

19.  +failover-end master mymaster 192.168.50.121 6379

本次故障转移完毕。

 20. +switch-master mymaster 192.168.50.121 6379 192.168.50.122 6379

故障转移完毕后，各个sentinel开始监控新的master。

这句话执行完毕后，我们可以去哨兵的配置文件中看到，sentinel monitor mymaster后面的ip已经发生了变化。