第 23 章：高可用架构

这是《PostgreSQL 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 高可用不只是“有一个备库”，还包括故障检测、切换决策、数据一致性、连接路由、演练和回切。

23.1 常见拓扑

一主一备：

App -> LB / HA entry
        |
     Primary
        |
     Standby

一主两备：

Primary -> Sync Standby
        -> Async Standby

同城双中心：

DC A: Primary + Witness
DC B: Sync/Async Standby

异地灾备：

同城主集群 -> 异地异步备库

23.2 RPO 与 RTO

同步复制降低 RPO，但增加延迟；异步复制性能更好，但故障可能丢最近 WAL。

23.3 故障检测

应检测：

1. 进程存活；
2. 端口健康；
3. 只读或读写状态；
4. 复制延迟；
5. WAL 保留；
6. 磁盘空间；
7. 事务成功率。

不要只 ping 端口。备库端口可用不代表可提升。

23.4 切换决策

切换前确认：

1. 主库是否真故障
2. 是否发生脑裂
3. 备库 LSN 是否追平
4. 复制模式是什么
5. 应用是否已停止写旧主
6. 新主是否可读写

防脑裂方式包括仲裁节点、STONITH、网络隔离策略和分布式锁，具体取决于 HA 方案。

23.5 连接路由

应用应通过稳定入口访问：

读写分离时，写请求必须到主库；强一致读也应到主库或等待回放。

23.6 HA 工具

常见方案：

选择标准：

1. 故障检测策略；
2. 一致性保证；
3. 恢复流程；
4. 运维复杂度；
5. 与监控集成；
6. 团队掌握程度。

23.7 备库冲突

查询可能取消回放：

ERROR: canceling statement due to conflict with recovery

相关参数：

SHOW hot_standby_feedback;
SHOW max_standby_streaming_delay;

hot_standby_feedback 可减少取消，但会让主库保留旧版本，增加膨胀风险。

23.8 演练

定期演练：

1. kill 主库进程；
2. 网络分区；
3. 同步备库宕机；
4. 复制断开；
5. WAL 归档失败；
6. 应用连接切换；
7. 旧主重建；
8. 回切。

本章小结

高可用架构要明确 RPO/RTO、复制模式、仲裁机制、路由策略和故障恢复。自动切换必须防脑裂，且所有方案都要经过真实演练。

思考题

1. 同步复制如何影响写入延迟？
2. RPO=0 是否等价于不会宕机？
3. 如何防止脑裂？
4. 备库查询冲突如何处理？
5. HA 演练应覆盖哪些场景？