被动故障检测

Pigsty 提供了四种 RTO 配置策略，下面是对三类故障场景下，不同 RTO 模式的最差，最优，平均 RTO 的计算逻辑与结果分析。

被动检测

节点宕机/网络分区场景（被动检测）RTO 对比

故障路径

RTO 计算公式：

RTO = TTL等待 + 从库检测 + 竞争锁 + promote + HAProxy_UP
    = (ttl - loop_wait ~ ttl) + (0 ~ loop_wait) + 选举 + HAProxy_UP

RTO 构成分析

RTO = TTL等待 + loop_wait + 选举(~1s) + HAProxy_UP
      \_____/   \______/
      主要固定成本  可变成本

• 固定成本：TTL 等待是最大成本（占 80%~87%），这是被动检测的本质代价
• 可变成本：从库检测延迟（0 ~ loop_wait）
• HAProxy 延迟：仅计算 rise × fastinter（UP 检测），DOWN 检测与选举并行，不在关键路径

TTL 等待时间的精确计算

Patroni Leader 每 loop_wait 续约一次，将 TTL 重置为完整值。当节点宕机时：

  续约周期示意图：
  
  ──────────────────────────────────────────────────────────────→ 时间
     │                    │                    │
   续约                  续约                  续约
   TTL=ttl              TTL=ttl              TTL=ttl
     │←── loop_wait ───→│
     
  如果故障发生在 Δt 处（续约后 Δt 时间）：
  TTL 剩余 = ttl - Δt
  由于 Δt ∈ [0, loop_wait)
  所以 TTL 等待 ∈ (ttl - loop_wait, ttl]

与主动检测（PG 崩溃）的关键差异

fast 模式

参数: ttl=20, loop_wait=5, inter=1s, fastinter=500ms, rise=2, fall=2

最好结果

最坏结果

平均结果

小结

fast 模式下节点宕机场景 RTO 范围为 17s ~ 29s，平均约 22s。TTL=20s 是主要耗时（占 80%），由于 loop_wait=5s 的续约频率，实际 TTL 等待范围被压缩到 15~20s。此配置适合同机房低延迟环境，追求最快的被动故障恢复。

norm 模式

参数: ttl=30, loop_wait=5, inter=2s, fastinter=1s, rise=2, fall=3

最好结果

最坏结果

平均结果

小结

norm 模式下节点宕机场景 RTO 范围为 28s ~ 41s，平均约 33s。TTL=30s 是主要耗时因素（占 83%）。这是生产环境的平衡选择，在故障恢复速度和集群稳定性之间取得折中。

safe 模式

参数: ttl=60, loop_wait=10, inter=3s, fastinter=1s, rise=2, fall=3

最好结果

最坏结果

平均结果

小结

safe 模式下节点宕机场景 RTO 范围为 53s ~ 78s，平均约 63s。TTL=60s 提供了充足的容错窗口（占 87%），能有效避免短暂网络抖动导致的误判。此配置适合对稳定性要求极高、可容忍分钟级中断的场景。

wide 模式

参数: ttl=120, loop_wait=30, inter=5s, fastinter=2s, rise=3, fall=5

最好结果

最坏结果

平均结果

小结

wide 模式下节点宕机场景 RTO 范围为 97s ~ 168s（约 1.6~2.8 分钟），平均约 128s（约 2.1 分钟）。TTL=120s 和 loop_wait=30s 提供极强的容错能力（TTL 占 82%），适合广域网/跨数据中心部署。此配置优先保证不误判，代价是故障切换时间较长。