Redis哨兵选举失败，如何排查monitor配置及仲裁节点数问题？

本文共计1029个文字，预计阅读时间需要5分钟。

《强盗选举失败，八成是quorum值和实际在线强盗数不匹配，或者sentinel监控配置不同步到全部节点。

为什么 sentinel monitor 配置不一致会导致选主卡死

哨兵不是靠本地配置文件启动后就一劳永逸的——sentinel monitor 这条指令定义了监控哪个主库、用什么名字、多少秒超时、quorum 是几。它会在哨兵间通过 hello 消息广播并协商生效。如果某台哨兵没收到完整广播（比如刚启动、网络抖动、或被防火墙拦截端口），它的 sentinel monitor 视图就跟别人不一样。

结果就是：一部分哨兵认为该故障转移，另一部分压根不认这个 master 名，甚至压根没在监控它。你执行 SENTINEL masters 会发现有的哨兵返回空，有的返回 fail 状态，但状态不统一。

• 检查方法：逐台连上哨兵，运行 SENTINEL masters 和 SENTINEL sentinels <master-name>，比对输出是否一致
• 常见诱因：新哨兵加入后没等够 30 秒（默认 sentinel default-down-after-milliseconds 的两倍）就触发故障；或某台哨兵长期失联后重启，缓存了旧的 monitor 配置
• 修复动作：不要只改配置文件，必须在每台哨兵上执行 SENTINEL monitor <name> <ip> <port> <quorum> 强制刷新，再用 SENTINEL ckquorum <name> 验证

quorum 设置为 2 却只有 1 个哨兵在线？那根本不会投票

quorum 不是“总共几个哨兵”，而是“最少几个哨兵同意才能发起故障转移”。它只在客观下线（odown）判定和 failover 投票两个环节起作用。设成 3，但当前只有 2 台哨兵能互相通信，SENTINEL ckquorum 就会直接报 missing+quorum，后续所有选举流程都不会启动。

• 典型错误：生产环境部署 3 台哨兵，但其中一台因防火墙策略无法与其他哨兵通信（如没开 26379 端口），实际形成两个孤立子集群
• 注意：quorum ≤ floor(N/2)+1 才能容忍单点故障；设为偶数（如 2 或 4）在 N=3 或 N=5 时反而容易分裂投票
• 别信配置文件里改完就生效——必须用 SENTINEL set <name> <option> <value> 动态写入，否则重启前仍是旧值

防火墙、NTP、rename-command 这三个坑最常被忽略

它们不直接出现在选举日志里，但会让哨兵连握手都失败，更别说投票了。

• 端口不通：26379（哨兵端口）必须双向互通；主从节点的 6379 也得让哨兵能连上，否则 SENTINEL slaves <name> 查不到从库，自然无法选主
• 时间不同步：哨兵依赖本地时间判断超时（如 down-after-milliseconds）。若节点间时钟差 > 5s，hello 消息会被当成过期丢弃，SENTINEL sentinels 返回的节点数会逐渐减少
• rename-command CONFIG：一旦重命名，哨兵在故障转移中调用 CONFIG REWRITE 持久化新主地址时失败，整个 failover 流程 abort，日志里只显示 failover-abort-no-good-slave，根本看不出是命令被禁用了

真正卡住的时候，别急着翻选举算法，先确认三件事：所有哨兵能不能互相 ping 通、SENTINEL ckquorum 是否通过、CONFIG 命令在目标从库上是否可用。这些检查 2 分钟内能做完，比重读 raft 论文快得多。