failover-timeout 是故障转移全流程的兜底时限，覆盖检测、选举、重配置及从节点复制对齐全过程；其值须大于最慢从节点同步耗时×parallel-syncs再加30秒缓冲，否则触发中止或震荡。
failover-timeout 不是“切换耗时上限”，而是整个故障转移生命周期的兜底时限
很多人一看到 failover-timeout 就以为它控制“主从切换要多久完成”，结果配成 10 秒，一遇网络抖动就失败回滚——新主刚选出来，同步还没开始，超时就触发了重试或中止。实际上，这个参数覆盖的是从检测失败、选举 leader、选出新主、从节点 reconfigure、到所有从节点完成复制起点对齐（REPLCONF listening-port 确认）的**完整闭环**。
-
failover-timeout默认是 180000 毫秒（3 分钟），不是“越小越快”，而是“必须大于实际最慢路径所需时间” - 典型耗时大户：从节点加载 RDB + 追赶增量 AOF（尤其大实例）、跨机房网络延迟、磁盘 I/O 峰值阻塞
- 若配置小于从节点全量同步耗时，哨兵会放弃本次 failover，并在日志里报
+failover-abort-not-elected或+try-failover-abort
怎么设才安全？看你的从节点同步能力，而不是主节点宕机时间
真正决定 failover-timeout 下限的，是你最慢那个从节点完成数据追平所需的时间，不是主节点挂了多久。线上出过太多事故：主节点 5 秒没响应（down-after-milliseconds 设为 5000），但 failover-timeout 却只设了 15000，结果同步卡在 18 秒，整个切换被强行中断，集群反复震荡。
- 用
redis-cli -p 6380 info replication | grep sync观察从节点上次全量同步耗时（master_sync_in_progress:0后的slave_repl_offset差值和耗时） - 压测时模拟一次 RDB 生成+传输+加载，记下最大耗时，再加 30% 余量 —— 这才是你该设的
failover-timeout - 常见保守值：
sentinel failover-timeout mymaster 120000（2 分钟）适用于中小实例；大数据量建议 ≥ 300000（5 分钟）
别忘了 parallel-syncs 和 down-after-milliseconds 的联动影响
failover-timeout 不是孤立参数。它和 parallel-syncs 共同决定“有多少从节点能并发追赶”，而 down-after-milliseconds 决定了“什么时候开始算超时”。三者配错，会形成负向叠加。
- 如果
parallel-syncs设为 1（默认），但你有 3 个从节点，那它们得串行同步 —— 总耗时 ≈ 单个同步 × 3，failover-timeout必须覆盖这个总和 - 若
down-after-milliseconds设得太短（比如 2000），哨兵可能因瞬时丢包频繁触发 failover 流程，每次都在failover-timeout边缘失败，导致“假故障真雪崩” - 推荐组合：
down-after-milliseconds≥ 5000，parallel-syncs根据带宽和磁盘 IO 调整（2～3），failover-timeout≥ 单节点同步最大耗时 ×parallel-syncs+ 30 秒缓冲
改完配置不 reload，等于没改；但 reload 有风险，得按顺序来
改完 sentinel.conf 里的 failover-timeout，不能只改文件就完事。哨兵不会自动热加载这个参数，必须 redis-cli -p 26379 sentinel set mymaster failover-timeout 120000 动态生效，或者重启哨兵进程 —— 但重启顺序错了，可能引发脑裂。
- 优先用
sentinel set：它只更新运行时参数，不影响当前监控和投票状态 - 避免直接
kill -HUP或 systemctl restart：哨兵进程重启瞬间会丢失部分 gossip 状态，若此时主节点恰好抖动，可能误判 - 多个哨兵节点要逐个更新，不要批量滚动 —— 防止不同步参数导致投票分裂（例如一个认为超时是 10 秒，另一个是 120 秒）
最常被忽略的一点：failover-timeout 对“已成功提升的新主节点”无效，但它会直接影响后续从节点能否顺利接入。很多团队调好了主切逻辑，却在恢复阶段发现旧主重新连入后被拒绝同步 —— 根本原因就是 timeout 太短，哨兵还没来得及广播新拓扑，就提前终止了配置分发流程。
