failover-timeout不是提速开关而是兜底时限，配错会导致+failover-abort-not-elected等日志频繁出现、切换中止及“假故障真雪崩”；其合理下限须大于最慢从节点全量同步耗时×parallel-syncs＋30000。
failover-timeout 不是“调小就能变快”的开关，配错反而会让切换失败或反复震荡。 它本质是整个故障转移流程的兜底时限，不是主节点下线判定时间，也不是新主选举耗时上限——真正卡住它的，是最慢那个从节点完成数据追平所需的时间。
failover-timeout 被误设为 10 秒后发生了什么
常见错误现象：+failover-abort-not-elected 或 +try-failover-abort 频繁出现在 Sentinel 日志里；主节点刚挂，新主刚选出来，INFO replication 显示从节点还在 loading 状态，超时就触发中止。
- 根本原因：10 秒远小于最慢从节点的全量同步（RDB 加载 + 增量复制）耗时
- 实际影响：每次 failover 都被 abort，哨兵反复尝试，形成“假故障真雪崩”
- 典型场景：从节点磁盘慢、网络带宽低、主节点写入压力大导致 repl-backlog 积压多
怎么算出合理的 failover-timeout 下限值
公式很简单：failover-timeout > (最慢从节点全量同步耗时) × parallel-syncs + 30000。注意这里不是平均值，而是你环境中实测过的“最慢一次”。
- 先在从节点上观察一次完整同步：杀掉从节点进程 → 启动 → 查看日志里
Background saving started by pid到SYNC with master complete的时间差 - 若
parallel-syncs设为 2，且最慢单次同步是 45 秒，则至少要设为45000 × 2 + 30000 = 120000（即 2 分钟） - 默认值
180000（3 分钟）在多数中小规模集群里是安全起点，别盲目下调
down-after-milliseconds 和 failover-timeout 的关系别搞混
这两个参数常被一起调，但作用完全不同：down-after-milliseconds 控制“什么时候认为主挂了”，failover-timeout 控制“挂了之后整个切换流程最多忍多久”。前者太小会误判，后者太小会中止。
- 比如设
down-after-milliseconds 2000，网络抖动丢两个包就触发 failover 流程，但此时failover-timeout若只有 10 秒，99% 会 abort - 生产建议：
down-after-milliseconds至少设为 30000（30 秒），避免瞬时抖动干扰；failover-timeout按实测同步时间推导，不跟它绑定调整 - 两者都调小 ≠ 切换变快，只是让系统更“敏感”和更“急躁”，风险远大于收益
最容易被忽略的一点：failover-timeout 还覆盖从节点重配置为新主的复制对齐过程。哪怕新主已选出，只要某个从节点还没追上 offset，超时一到就回滚。所以别只盯着选举时间，得盯住最慢那个从节点的复制能力。
