细的异常情况如下所述。
old master部署在ip为xx.xx.234.67的机器上且port默认为6379，sentinel切换异常后，对该old master执行info命令输出如下：
slave-00实例在ip为xx.xx.234.49的机器上且port配为6378，sentinel切换异常后，info输出如下：
slave-01实例在ip为xx.xx.234.49的机器上（与slave-00同机部署）且port配为6377，info输出如下：
从上面3个redis实例的输出情况看，3个均认为自己是slave，整个系统无主！其中，位于xx.xx.234.67的old master（注意上面第1图的master_host字段）和位于xx.xx.234.49的salve-00（注意上面第2图的master_host字段）均认为slave-01为new master，而位于xx.xx.234.49的slave-01则认为自己仍然为slave，认为old master目前还是master（注意上面第3图的master_host字段）。
从sentinel进程日志看，其无法选出新主，即sentinel无法确认两个master candidates到底哪个是new master，在两个实例间频繁切换：
这种情况务在实际运维时务必要引起注意！
Case 6: 在系统已进入Case5所示的异常状态后，shutdown两个master candidates中的一个实例，sentinel仍然无法正常选主，直至3个实例全部shutdown，整个系统仍然无主。基本可以确定监控系统内部逻辑状态已经混乱了。
2.4 结论
若master实例故障，则最好等sentinel选出new master且稳定后（选新主并完成切换的时间与配置有关，典型值在1分钟之内），再重启old master，避免引发sentinel的误判，导致整个系统无法选出new master。
【参考资料】
1. Redis Sentinel Documentation