提示：从上面的状态信息可以看到当前sentinel监控的master是出于正常ok状态，有两个slave和3个sentinel；对于192.168.0.41：26379目前有3个客户端连接，二个是sentinel，一个本机；到此3台sentinel搭建启动完成；
验证：把master宕机，看看sentinel是否将在两个从节点选举一个为新master？是否将另外一个slave重新指向新master？
在slave01上查看主从同步信息
提示：第一次查看只是告诉我们master宕机了，第二次查看就告诉我们当前节点为master，并且拥有一个slave节点，这说明已经完成了故障转移，slave01已经被提升为新的master了；
在192.168.0.43上查看主从信息，看看是否指向新的master？
提示：在slave02上看主从同步信息，可以看到slave02已经从属新master了；
查看故障转移时 sentinel日志
提示：从上面的日志信息可以了解到，在从sdown到odown后，就会触发vote算法开始选举leader；然后将原master降级为slave，然后将选举出来的leader原salve属性去除（slaveof no one）;然后提升新master，然后将剩下的slave重新配置新master为主；最后是切换master，开始新的监控；
查看故障 转移后的 redis 配置文件
提示：故障转移后 redis.conf 中的 slaveof 行的 master IP 会被修改，sentinel.conf 中的 sentinel monitor IP 会被修改。同时在sentinel配置文件的末尾还会有添加known-slave和known-sentinel等信息；
修复旧master 让其重新上线
提示：把原master启动后，它自动就成为了新主的slave；这主要是因为sentinel在故障转移时把其配置文件中的slaveof 修改成新的master地址了；
在新master上查看主从同步信息
提示：在没有恢复原master时，在新master上查看主从同步信息，只能看到一个salve，启动原master后，在看就有两个slave是在线；
总结
到此这篇关于Redis服务之高可用组件sentinel的文章就介绍到这了,更多相关Redis服务之高可用组件sentinel内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
