missing+quorum表示哨兵故障转移因在线节点数不足quorum值而卡死，根本原因是存活哨兵数＜配置的quorum值，需用SENTINEL ckquorum验证并逐台SENTINEL set更新，不可仅改配置文件。
哨兵日志里反复出现 missing+quorum 是什么信号
这说明哨兵集群在尝试发起故障转移时，无法凑够法定票数（quorum），直接卡死。根本原因不是主库挂了，而是参与投票的哨兵节点数 少于 quorum 配置值——比如你设了 quorum 3，但当前只有 2 个哨兵在线，那永远投不出结果。
常见错误现象：
• 主库已宕机，但从库没升主，整个集群只读
• SENTINEL masters 显示 failover-abort-no-good-slave 或压根没触发 failover
• SENTINEL sentinels <master-name> 返回的哨兵列表明显少于预期
- 检查实际存活哨兵数：用
redis-cli -p 26379 SENTINEL sentinels mymaster看返回几条记录，不是看进程或容器数量 -
quorum值必须 ≤ 当前可通信哨兵节点数，建议设为⌈N/2⌉ + 1（N 是部署的哨兵总数），例如 5 个哨兵，quorum设 3；3 个哨兵就只能设 2 - 别把
quorum和哨兵总数量混淆——它只是“最少需要几个同意”，不是“总共要部署几个”
为什么改完 sentinel.conf 的 quorum 还不生效
哨兵不会热重载 quorum 配置。这个值只在初始化连接和收到其他哨兵的 hello 消息时协商确认，改完配置不重启等于白改。
使用场景：滚动更新哨兵、临时扩容/缩容、修复误配
- 必须逐台执行
redis-cli -p 26379 SENTINEL set mymaster quorum <new-value>，而不是改文件后 reload - 执行后立刻用
SENTINEL master mymaster查看quorum字段是否更新，注意它显示的是当前协商出的有效值，不是配置文件里的原始值 - 如果某台哨兵长期失联，它上次广播的
quorum可能被缓存，新哨兵加入后需等待sentinel monitor配置同步完成才能参与投票
SENTINEL ckquorum 能查什么，不能查什么
这是唯一能快速验证当前 quorum 是否可达成的命令，但它只做静态检查：确认「活着的哨兵数 ≥ 配置的 quorum 值」，不模拟故障转移全流程。
性能 / 兼容性影响：毫秒级响应，无副作用，Redis 3.2+ 支持
- 运行
SENTINEL ckquorum mymaster，返回OK表示票数够，ERR表示不够（并提示缺几个） - 它不检查网络分区——比如 3 个哨兵物理都在线，但 A 和 B 能通、C 只能和 A 通，此时
ckquorum可能返回 OK，但真实故障转移仍可能失败 - 它不校验从库状态，哪怕所有哨兵都在线，若没有健康从库（比如全部
slave-priority 0或延迟超限），照样无法选主
哨兵节点数少于 3 时的现实约束
2 个哨兵 + quorum 2 理论可行，但极脆弱：任意一个哨兵短暂失联，quorum 就立即失效。生产环境几乎没人这么干。
容易踩的坑：
• 在测试环境用 1 个哨兵 + quorum 1，上线后照搬配置，结果一节点抖动就脑裂
• Kubernetes 里用 StatefulSet 部署 3 个哨兵，但没配反亲和性，全调度到同一台 Node，Node 故障导致全部离线
- 最低可用组合是 3 哨兵 +
quorum 2，容忍 1 个节点故障 - 如果只能部署 2 个哨兵，
quorum必须设为 1，但必须接受「单点判定即生效」的风险——比如网络抖动导致哨兵误判主库下线，会直接切主 - 监控项要盯紧
sentinel_masters的num-sentinels和num-slaves，这两个数字突降比 CPU 或内存告警更致命
quorum 不是调得越大越安全，它和哨兵存活率是硬冲突。真正难的不是算数字，是让每个哨兵在各种网络条件下都能稳定交换 hello 消息——这点常被忽略。
