利弊权衡

高可用系统设计的核心是在 可用性 与 一致性 之间找到平衡。Pigsty 通过 RTO 和 RPO 两个关键参数，让您根据业务需求灵活调整这一权衡。

核心指标

RTO（恢复时间目标）

Recovery Time Objective：从故障发生到服务恢复的最长时间。

• 影响因素：故障检测时间、领导者选举时间、流量切换时间
• 默认值：30 秒
• 调整范围：15s ~ 60s（不建议更低或更高）

RPO（恢复点目标）

Recovery Point Objective：可接受的最大数据丢失量。

• 影响因素：复制延迟、是否启用同步复制
• 默认值：1MB（异步复制）
• 调整范围：0（同步复制）~ 无限大

参数配置

pg_rto

pg_rto: 30  # 恢复时间目标，单位：秒

此参数用于计算 Patroni 的 TTL 值：

• 减小 RTO：更快检测故障，更快切换，但增加误报风险
• 增大 RTO：减少因网络抖动触发的误切换，但故障恢复时间更长

建议：

pg_rpo

pg_rpo: 1048576  # 恢复点目标，单位：字节（1MB）

此参数控制自动故障切换时允许的最大数据丢失：

• 当候选从库落后主库超过此值时，拒绝自动切换
• 需要人工确认后才能强制切换

建议：

配置模板

Pigsty 提供了预置的配置模板，对应不同的权衡策略：

oltp.yml（默认）

优化在线事务处理，可用性优先。

pg_conf: oltp.yml
pg_rto: 30
pg_rpo: 1048576  # 1MB

• 异步复制，性能最优
• 故障时可能丢失 < 1MB 数据
• 适合大多数 Web 应用、业务系统

crit.yml

关键业务模板，一致性优先。

pg_conf: crit.yml
pg_rto: 30
pg_rpo: 0

• 同步复制，确保零数据丢失
• 写入延迟增加（等待从库确认）
• 从库故障会影响主库写入性能
• 适合金融、支付等关键业务

olap.yml

优化分析查询，吞吐量优先。

pg_conf: olap.yml
pg_rto: 60
pg_rpo: 10485760  # 10MB

• 异步复制，大内存缓冲
• 故障检测时间更长
• 适合数据仓库、报表系统

权衡决策树

是否可接受任何数据丢失？
    │
    ├── 否 → 使用 crit.yml（同步复制，RPO=0）
    │         ├── 代价：写入延迟增加，从库故障影响主库
    │         └── 适用：金融、支付、核心交易
    │
    └── 是 → 可接受多少数据丢失？
              │
              ├── < 1MB（几秒数据）→ 使用 oltp.yml（默认）
              │         ├── 代价：极端故障丢失 < 1MB
              │         └── 适用：大多数在线业务
              │
              └── > 1MB → 根据需求调整 pg_rpo
                        ├── 代价：更多数据丢失风险
                        └── 适用：日志、分析、可重放数据

常见场景

场景一：电商系统

需求：高可用，可接受极少量订单丢失

pg_conf: oltp.yml
pg_rto: 30
pg_rpo: 1048576

理由：订单丢失可通过客服/重试补救，优先保证系统可用

场景二：银行核心系统

需求：零数据丢失，可接受略高延迟

pg_conf: crit.yml
pg_rto: 30
pg_rpo: 0

理由：资金交易不可丢失，宁可牺牲性能

场景三：日志分析平台

需求：高吞吐，数据可重新采集

pg_conf: olap.yml
pg_rto: 60
pg_rpo: 104857600  # 100MB

理由：日志可重新收集，优先保证写入性能

注意事项

1. RTO 并非越低越好

   • 过低的 RTO 会导致网络抖动时频繁触发误切换
   • 每次切换都有业务闪断，频繁切换比一次长时间故障更糟糕

2. RPO = 0 不是免费的

   • 同步复制会增加写入延迟（需等待从库确认）
   • 当所有同步从库不可用时，主库无法接受写入

3. HA 不能替代备份

   • 高可用应对硬件故障，备份应对逻辑错误
   • DROP TABLE 会立即复制到所有从库
   • 需配合 PITR 应对人为误操作

4. 定期验证

   • 通过 switchover 定期验证故障切换流程
   • 确保备份可恢复，而不只是"看起来在备份"