故障时序模型

• 1: 被动故障检测
• 2: 主动故障检测
• 3: 人工故障切换

1 - 被动故障检测

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%），适合广域网/跨数据中心部署。此配置优先保证不误判，代价是故障切换时间较长。

2 - 主动故障检测

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

RTO 计算

主动检测

PG 崩溃场景（主动检测）RTO 对比

故障路径

注意：HAProxy 检测旧主 DOWN 与 Patroni 流程并行执行，在 promote 完成前早已完成，不计入 RTO。

RTO 计算公式：

RTO = loop_wait + primary_start_timeout + loop_wait + 选举 + HAProxy新主UP
    = 2 × loop_wait + primary_start_timeout + 选举 + HAProxy新主UP

RTO 构成分析

RTO = 2 × loop_wait + primary_start_timeout + 选举(~1s) + HAProxy新主UP
      \_________/   \__________________/
       可变成本           固定成本

• 固定成本：primary_start_timeout 是最大的固定成本，占 RTO 的 27%~96%
• 可变成本：主要来自 2 × loop_wait（主库检测 + 从库检测），最坏情况两者都是满值
• HAProxy 延迟：仅计算 rise × fastinter（新主上线检测），约 1~15s
• HAProxy 旧主 DOWN：与 Patroni 流程并行执行，在 promote 完成前早已完成，不计入 RTO

与被动检测（节点宕机/网络分区）的差异：节点宕机时 Patroni 也死了，无法主动释放锁，只能等 TTL 过期被动触发。 而 PG 崩溃时 Patroni 还活着，会主动尝试恢复 PG，primary_start_timeout 决定了等待多久才放弃。

fast 模式

最好结果

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

最坏结果

平均结果

小结

fast 模式下 PG 崩溃场景 RTO 范围为 7s ~ 19s，平均约 12s。primary_start_timeout=5s 是固定成本，两个 loop_wait 周期（0~10s）是主要变量。此配置适合同机房低延迟环境，能快速完成故障切换。

norm 模式

参数: loop_wait=5, primary_start_timeout=15, inter=2s, fastinter=1s, rise=2, fall=3

最好结果

最坏结果

平均结果

小结

norm 模式下 PG 崩溃场景 RTO 范围为 18s ~ 31s，平均约 23s。primary_start_timeout=15s 给了 PG 一定的本地恢复机会（如 crash recovery），同时保持了合理的 RTO。这是生产环境的推荐配置，平衡了故障恢复速度和误判风险。

safe 模式

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

最好结果

最坏结果

平均结果

小结

safe 模式下 PG 崩溃场景 RTO 范围为 63s ~ 88s，平均约 73s。primary_start_timeout=60s 给大型数据库充足的 crash recovery 时间，降低不必要的 failover。此配置适合数据安全性要求极高、可容忍分钟级中断的场景。

wide 模式

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

最好结果

最坏结果

平均结果

小结

wide 模式下 PG 崩溃场景 RTO 范围为 127s ~ 198s（约 2~3 分钟），平均约 158s（约 3 分钟）。primary_start_timeout=120s 和 loop_wait=30s 提供极强的容错能力，适合广域网/跨数据中心部署。此配置优先保证不误判，代价是故障切换时间较长。

被动探测

手动触发

3 - 人工故障切换

Switchover / Failover 场景（人工触发）RTO 对比

Switchover（计划内优雅切换）

故障路径

准备阶段（老主库仍可用，不计入 RTO）：

RTO 计时阶段（服务不可用）：

RTO 计算公式：

RTO = WAL追平 + 锁切换 + promote + HAProxy_UP

RTO 构成分析

RTO = WAL追平 + 锁释放(~0.3s) + 锁获取(~0.2s) + promote(~0.5s) + HAProxy_UP
      \______/
      同步复制时为0

• WAL 追平：同步复制模式下为 0（已实时同步）；异步复制时取决于复制延迟
• 锁切换：DCS 两次原子操作（释放 + 获取），约 0.3~1s
• HAProxy 延迟：rise × fastinter

与 Failover 的差异

fast 模式

参数: inter=1s, fastinter=500ms, rise=2

最好结果

最坏结果

平均结果

小结

norm 模式

参数: inter=2s, fastinter=1s, rise=2

最好结果

最坏结果

平均结果

小结

safe 模式

参数: inter=3s, fastinter=1s, rise=2

最好结果

最坏结果

平均结果

小结

wide 模式

参数: inter=5s, fastinter=2s, rise=3

最好结果

最坏结果

平均结果

小结

Failover（强制切换）

故障路径

RTO 计算公式：

RTO = 验证 + 获取锁 + promote + HAProxy_UP

说明：Failover 通常在主库已故障时使用，此时 RTO 从执行命令开始计时（主库已不可用）。

fast 模式

norm 模式

safe 模式

wide 模式

人工触发汇总

Switchover vs Failover 对比

关键洞察

1. Switchover 与 Failover RTO 非常接近
   • 差异仅在于 WAL 追平时间（同步复制时为 0）
   • 同步复制模式下，两者 RTO 几乎相同
2. HAProxy 检测是主要延迟来源
   • 在人工触发场景中，HAProxy UP 检测占总 RTO 的 43%~65%
   • wide 模式下 HAProxy 延迟更为显著
3. 与自动故障检测的对比

人工触发比自动检测快 6~20 倍，因为跳过了 primary_start_timeout 和 TTL 等待 这两个最大的时间消耗。