―-场景3：master宕机
master-sentinel作为master 1的leader，会选取一个master 1的slave作为新的master。slave的选取是根据一个判断DNS情况的优先级来得到，优先级相同通过runid的排序得到，但目前优先级设定还没实现，所以直接获取runid排序得到slave 1。
然后发送命令slaveof no one来取消slave 1的slave状态来转换为master。当其他sentinel观察到该slave成为master后,就知道错误处理例程启动了。sentinel A然后发送给其他slave slaveof new-slave-ip-port 命令，当所有slave都配置完后，sentinel A从监测的masters列表中删除故障master，然后通知其他sentinels。
关闭master:
![这里写图片描述](https://www.cppentry.com/upload_files/article/57/1_wkj9h__.png "\")
查看sentinel状态：
6379-sentinel:
自动将slave2即6579切换成master，原来的master变成slave。
![这里写图片描述](https://www.cppentry.com/upload_files/article/57/1_n3t3r__.png "\")
6579-sentinel:
显示了failover的过程：
![这里写图片描述](https://www.cppentry.com/upload_files/article/57/1_ygq4u__.png "\")
―-场景4：master恢复
重新启动原来的master：
redis-server /usr/local/redis_cluster/master-6379/redis.conf
查看sentinel状态：
原来的master自动切换成slave，不会自动恢复成master：
![这里写图片描述](https://www.cppentry.com/upload_files/article/57/1_x3hlw__.png "\")
测试完成。
注意：若在sentinel已选出新主但尚未完成其它实例的reconfigure之前，重启old master，则整个系统会出现无法选出new master的异常。