哨兵机制

  • 哨兵机制是实现主从库自动切换的关键机制，有效地解决了主从复制模式下故障转移的问题

哨兵机制的基本流程

  • 监控：
    1. 指哨兵在进程运行时，会周期性的给所有主从库发送 PING 命令，来检测他们是否仍在运行
    2. 如果没有在规定的时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”
    3. 如果是主库没有在规定的时间内响应哨兵的 PING 命令，哨兵就会判定主库下线，开始自动切换主库的流程

  • 选主：
    1. 我们在多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。通过检查从库的当前在线状态和判断它之前的网络连接状态进行筛选
    2. 然后我们再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库。依次按照：从库优先级、从库复制进度以及从库 ID 号进行选定

  • 通知：
    1. 哨兵会把新主库的连接信息发给其他从库，让它们执行 replicaof 命令，和新主库建立连接，并进行数据复制
    2. 哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上

选主

  • 筛选：通过配置项 down-after-milliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库
  • 规则：

    1. 从库优先级（slave-priority 配置项设置不同优先级）

    2. 从库复制进度（挑选从库和旧主库的同步进度最高的。主库会用 master_repl_offset 记录当前的最新写操作，而从库会用 slave_repl_offset 这个值记录当前的复制进度。slave_repl_offset最接近 master_repl_offset 就可以选定为主库）

    3. 从库 ID 号（在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库）


主观下线与客观下线

  • 如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”
  • 在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”

（哨兵集群：通常会采用多实例组成的集群模式进行部署。通过引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。）



参考