两阶段下线判定
哨兵判断主库是否真的不可用分两步。第一步是主观下线（SDOWN）：某台哨兵在 down-after-milliseconds 时间内收不到主库回应，就把标记改为 s_down，这只是单台哨兵的视角。第二步是客观下线（ODOWN）：这台哨兵向其他哨兵求证，达到 quorum 数量（含自己）都认为主库不可达，才升级为 o_down，之后才进入领导者选举与故障转移。这个两阶段设计把「单点观察到的抖动」和「多数确认的故障」区分开来。
基本信息
| SDOWN 触发 | 由 down-after-milliseconds 的判定窗口决定 |
|---|---|
| ODOWN 触发 | 达到 quorum 数量的哨兵一致确认 |
| 哨兵间交互 | IS-MASTER-DOWN-BY-ADDR 询问与应答 |
| 查看方式 | SENTINEL MASTER 看 flags，SENTINEL SENTINELS 看同伴 |
| 有效期 | ODOWN 只对本次判定有效，主库恢复即清除 |
典型使用场景
- 切换迟迟没发生，先判断卡在 SDOWN 还是 ODOWN 阶段
- 调整 down-after-milliseconds，给跨机房这类抖动较多的链路留容忍度
- 核对 quorum 设置是否合理，过小会放大误判、过大可能永远无法确认下线
- 故障复盘中还原「谁先报告、何时跨过多数派」的时间线
- 多套主库共用一个哨兵集群时，确认各监控对象的 quorum 互相独立
观察判定状态
观察判定状态
redis-cli -p 26379 PING # 先确认哨兵自己活着
redis-cli -p 26379 SENTINEL MASTER mymaster # flags 里是否出现 s_down / o_down
redis-cli -p 26379 SENTINEL MASTER mymaster | grep -E 'flags|quorum|down-after'
redis-cli -p 26379 SENTINEL SENTINELS mymaster # 查看其他哨兵的观察结果
redis-cli -p 26379 SENTINEL CKQUORUM mymaster # 检查当前是否还能达到法定票数状态字段读法
| 状态 | 含义 | 后续动作 |
|---|---|---|
| s_down | 单台哨兵认为主库不可达 | 观察其他哨兵是否同样报告，先排除抖动 |
| o_down | 达到 quorum 一致确认 | 进入选举与切换流程，跟踪切换结果 |
| 仅一台报 s_down | 各哨兵观察不一致 | 检查哨兵之间的网络连通与配置是否统一 |
| quorum 不合理 | 过小放大误判，过大难以确认 | 按哨兵总数重新规划 quorum |
ODOWN 只在这一次判定中有效：主库恢复响应后标志会清除，也不会继续触发切换。若故障期间某台哨兵自身不可达，其他哨兵拿不到它的确认，ODOWN 可能迟迟建立不起来，表现就是「主库确实挂了但没有发生切换」。