主节点宕机后哨兵未选新主，大概率卡在sdown阶段无法升级为odown；原因包括down-after-milliseconds设置不当、quorum未达成、网络分区、哨兵间通信中断或sentinel_tilt=1导致主观下线暂停。
主节点宕机后哨兵没选新主，大概率不是“没反应”，而是卡在主观下线（SDOWN）阶段，迟迟升不到客观下线（ODOWN）——down-after-milliseconds 设得过大或过小，都会直接堵死这一步。
为什么改了 down-after-milliseconds 主库挂了也不切？
常见现象是日志里反复出现 +sdown master mymaster，但始终不见 +odown master mymaster 和 +switch-master。这说明：单个哨兵确实判定主节点 SDOWN 了，但其他哨兵还没达成共识。
- quorum 没凑够：比如你配了
quorum 2，但只有 1 个哨兵因超时标记 SDOWN，其余哨兵还在等响应，ODOWN 就不会触发 - 网络分区：哨兵之间发不了
__sentinel__:hello心跳，彼此看不到对方的投票，客观下线永远无法形成 -
down-after-milliseconds设得太大（如 60000），而真实故障发生时，部分哨兵因网络延迟稍高、还没到阈值，就拖慢整体判定节奏 - 哨兵自身负载高或时钟异常：
sentinel_tilt为 1 时，所有主观下线判定会暂停，需检查ntpq -p和 CPU 使用率
怎么确认当前生效的 down-after-milliseconds 值？
别只看配置文件。每个哨兵独立加载自己的配置，改完不重启或不推送，就是白改。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 连上哨兵端口（默认 26379）：
redis-cli -p 26379 - 执行：
SENTINEL CONFIG GET mymaster down-after-milliseconds - 返回类似：
1) "down-after-milliseconds" 2) "5000"—— 这才是它真正在用的值 - 多个哨兵要逐个查，不能只查一个
局域网和跨机房场景下，down-after-milliseconds 怎么设才不卡住？
这个值不是拍脑袋定的，必须匹配你的链路稳定性。设错的结果不是“慢一点”，而是“根本不走下一步”。
- 同机房部署：从
3000起步，观察日志中+sdown出现频率；若偶发抖动就跳变，逐步提到5000～8000 - 跨机房或含公网链路：直接设
15000，并同步调大sentinel ping-reply-timeout到2000（默认 1000） - 绝对不要让
down-after-milliseconds小于探测间隔（即sentinel monitor第四个参数）；例如探测间隔是 10000，那它至少得设成10000，否则哨兵可能一次都没重试就判下线 - 主库有慢查询毛刺？用
SLOWLOG GET看最长耗时，down-after-milliseconds应明显长于该值（比如毛刺最长 200ms，那就别设低于3000）
真正容易被忽略的是：哪怕所有哨兵都标了 SDOWN，如果它们之间通信断了，ODOWN 就永远不会发生。所以排查时先看 sentinel_masters 是否突降为 0，再看 sentinel_tilt 是否为 1，最后才动 down-after-milliseconds。参数只是杠杆，支点不在它身上。
