这也是常用的架构,,MASTER用于写服务,SLAVE提供读服务 但是存在弊端, 就是主MASTER宕机后, SLAVE无法升级, 导致无法提供写服务
为了解决主从架构的MASTER宕机问题, 架构引入哨兵监控机制, 一般哨兵也是集群,最少节点为3, 为什么呢
应为单哨兵, 可能存在主观下线问题, 因为网络的延迟波动, 导致单哨兵主观认为MASTER节点宕机, 导致其被强制下线, 但是其实是应为网络波动的问题, MASTER并没有问题
为了解决主观下线问题, 所以需要哨兵节点至少为3, 而确认需要配置为2, 只有哨兵集群中2个哨兵同时认为MASTER节点宕机, MASTER才会被下线, 解决了单哨兵的主观下线问题, 从而达到故障转移, 多哨兵, 那么由谁去做故障转移呢, 那么就会设计到哨兵的Leader选举机制
采用投票机制, 3个哨兵中, 谁获得的票数高, 谁就会成为Leader, 进行故障准一的工作
当leader对其中一台SLAVE升级之后, 其他的SLAVE会将MASTER切换为当前新上任的MASTER, 并且新MASTER会给所有的SLAVE进行数据同步,, 并且哨兵集群将继续监控
当原来的MASTER被修复后,重新复活, 被哨兵检测到, 会自动将其降级成SLAVE并加入当前的集群中, 然后新MASTER对其进行数据同步, 复活的MASTER并不会成为MASTER, 而是服从新MASTER的安排, 自身为SLAVE