+sdown 表示单个哨兵认定主节点失联，+odown 才是触发故障转移的共识临界点；两者时间差暴露网络或配置问题，+odown 后还需经选举、选从库、提升等步骤才能完成切换。
怎么看日志里 +sdown 和 +odown 这两行？
日志中出现 +sdown 表示某个哨兵单方面认定主节点失联，不等于故障转移开始；+odown 才是真正触发切换的临界点——它意味着至少 quorum 个哨兵已达成共识。两者时间差往往暴露网络抖动或配置不合理。
-
+sdown master mymaster 192.168.1.101:6379 @ mymaster 192.168.1.101:6379：仅本哨兵视角，未通知他人，也不影响其他哨兵决策 -
+odown master mymaster 192.168.1.101:6379 @ mymaster 192.168.1.101:6379 #quorum 2/2：已满足仲裁数（此处 2/2 表示共 2 个哨兵，全部投了 SDOWN），立刻进入选举流程 - 若只看到
+sdown却迟迟无+odown，常见原因是哨兵间通信失败（防火墙挡了26379端口）或quorum设得过高（比如 3 节点哨兵却设quorum 3）
down-after-milliseconds 和 quorum 怎么配才不误判？
这两个参数共同决定“什么时候该信、信多少人”，配错会导致频繁切换或切换滞后。它们不是独立调优项，必须一起看。
-
down-after-milliseconds太小（如设成5000）：网络瞬断就触发sdown，容易引发雪崩式odown和无效选举 -
quorum太大（如 5 节点哨兵设quorum 5）：只要一个哨兵因 GC 或负载高漏报，就卡在sdown阶段，主库真挂了也切不动 - 生产推荐组合：
down-after-milliseconds 30000+quorum = N/2 + 1（N 为哨兵总数，且 N ≥ 3）；例如 3 哨兵用quorum 2，5 哨兵用quorum 3 - 注意：
quorum不是“投票数上限”，而是最小共识数；它不影响哨兵间通信频率，但直接控制odown的生成条件
从 +odown 到新主上线，中间还卡在哪？
+odown 只是故障转移的起点，后续每一步都可能失败并静默回退——此时日志里不再打 +failover，但你会看到客户端连不上、从库没跟上、旧主无法降级等现象。
- Leader 选举失败：哨兵需先选出一个 Leader（类似 Raft），若超时（默认
failover-timeout180 秒）未达成，则整个切换中断；检查日志是否有+try-failover但无+selected-slave - 从库筛选被拒：候选从库若满足任一条件就会被跳过——
slave-priority 0、复制偏移量落后太多、INFO 回复超时、与旧主断连超max-master-down-time（默认 3xdown-after-milliseconds） - SLAVEOF NO ONE 执行失败：目标从库返回错误（如正在 bgsave、内存满），哨兵不会重试，而是立即放弃该从库，轮到下一个；查日志中
failover-abort-no-good-slave即为此因
为什么修好旧主后，它变不回主库？
旧主恢复后默认以从库身份加入集群，这是设计使然，不是 bug。哨兵不会自动把它“升回去”，因为这会破坏数据一致性（尤其在异步复制场景下，旧主可能丢数据）。
- 它重新上线时，哨兵会发
SLAVEOF <new-master>命令，强制其同步新主——前提是它的runid和复制偏移量没被新主拒绝 - 若你执意要它回主，必须手动执行
SENTINEL failover mymaster（由任一哨兵触发），且确保它当前状态满足参选条件（非sdown/非odown、有足够复制进度） - 最容易忽略的一点：旧主的
redis.conf若仍含slaveof配置，重启后会主动连老地址，导致和哨兵指令冲突；务必清空或注释掉该行
+sdown 都是单点观察，而 +odown 是集群对现实的集体确认——但这个“确认”本身依赖通信、时序和配置三者严丝合缝，少一环，生命周期就停在半路。 
