京公网安备11010502063487号一个 sentinel 觉得主库挂了(sdown)还不够,要 quorum 个 sentinel 同意才是客观下线(odown),才会触发故障转移。这篇改变 quorum 与可用 sentinel 的数量,看每种组合下每个 sentinel 眼中主库的状态怎么变。
sentinel0: master,disconnected@1ms s_down,master,disconnected@3161ms s_down,o_down,master,disconnected@3236ms
sentinel1: master,disconnected@1ms s_down,master,disconnected@3102ms s_down,o_down,master,disconnected,failover_in_progress@3164ms
sentinel2: master,disconnected@2ms master@1037ms s_down,master,disconnected@3075ms s_down,o_down,master,disconnected@4185ms
新主库地址: ('127.0.0.1', 7701)每个 sentinel 先各自 s_down;再通过 SENTINEL is-master-down-by-addr(sentinel 之间的询问命令,这一点来自文档)互相确认,凑够 quorum 就 o_down,然后由第一个准备好的 sentinel 进入 failover_in_progress。sentinel2 的记录里在 1 秒时有一次短暂回到 master,是重连尝试的瞬时状态。
sentinel0: master,disconnected@1ms master@59ms s_down,master@3150ms s_down,master,disconnected@3182ms
sentinel1: master,disconnected@2ms s_down,master,disconnected@3118ms
12 秒后主库地址: ('127.0.0.1', 7700) (未切换)
解冻第 3 个 sentinel 之后:
sentinel0: s_down,master,disconnected@0ms
sentinel1: s_down,master,disconnected@1ms
sentinel2: master,disconnected@3ms master@1042ms
新主库地址: ('127.0.0.1', 7700)剩下的两个 sentinel 各自 s_down 但凑不够 3 票:没有 o_down,也就没有故障转移。解冻第三个 sentinel 之后 15 秒里我仍没有等到切换——被冻结过的 sentinel 没有及时标出 s_down,原因我没有追查。实践上:quorum 不要设成 sentinel 总数,要允许少数 sentinel 不可用。
sentinel0: master,disconnected@1ms s_down,o_down,master,disconnected@4126ms sentinel1: master,disconnected@1ms s_down,o_down,master,disconnected,failover_in_progress@3049ms sentinel2: master,disconnected@2ms s_down,o_down,master,disconnected@3049ms
quorum 为 1 时,任何一个 sentinel 的 s_down 立刻就是 o_down。反应最快,但单个 sentinel 与主库之间的网络问题就足以触发切换。
另外要注意:quorum 只决定「客观下线」,真正执行故障转移还需要多数 sentinel 授权(第 88 篇)。