哨兵选举失败主因是quorum值与在线哨兵数不匹配或sentinel monitor配置未同步：配置通过hello广播协商，不一致会导致部分哨兵不识别主库，SENTINEL masters输出不统一；须逐台执行SENTINEL monitor强制刷新并用SENTINEL ckquorum验证，同时排查防火墙、NTP偏移及CONFIG命令重命名问题。
哨兵选举失败，八成是 quorum 值和实际在线哨兵数对不上，或者 sentinel monitor 配置没同步到全部节点。
为什么 sentinel monitor 配置不一致会导致选主卡死
哨兵不是靠本地配置文件启动后就一劳永逸的——sentinel monitor 这条指令定义了监控哪个主库、用什么名字、多少秒超时、quorum 是几。它会在哨兵间通过 hello 消息广播并协商生效。如果某台哨兵没收到完整广播（比如刚启动、网络抖动、或被防火墙拦截端口），它的 sentinel monitor 视图就跟别人不一样。
结果就是：一部分哨兵认为该故障转移，另一部分压根不认这个 master 名，甚至压根没在监控它。你执行 SENTINEL masters 会发现有的哨兵返回空，有的返回 fail 状态，但状态不统一。
- 检查方法：逐台连上哨兵，运行
SENTINEL masters和SENTINEL sentinels <master-name></master-name>，比对输出是否一致 - 常见诱因：新哨兵加入后没等够 30 秒（默认
sentinel default-down-after-milliseconds的两倍）就触发故障；或某台哨兵长期失联后重启，缓存了旧的monitor配置 - 修复动作：不要只改配置文件，必须在每台哨兵上执行
SENTINEL monitor <name><ip><port><quorum></quorum></port></ip></name>强制刷新，再用SENTINEL ckquorum <name></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></value></option></name>动态写入，否则重启前仍是旧值
防火墙、NTP、rename-command 这三个坑最常被忽略
它们不直接出现在选举日志里，但会让哨兵连握手都失败，更别说投票了。
- 端口不通：
26379（哨兵端口）必须双向互通；主从节点的6379也得让哨兵能连上，否则SENTINEL slaves <name></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 论文快得多。
