PostgreSQL 生产工具栈与高可用
从连接池、备份恢复、监控和故障域出发设计 PostgreSQL 生产架构，并判断 PgBouncer、pgBackRest、Patroni、CloudNativePG 与 Pigsty 何时值得采用
生产 PostgreSQL 的优先级通常是：能够恢复 → 不耗尽连接 → 看得见问题 → 安全地变更 → 再自动故障切换。高可用不能替代备份，副本也不能修复已经复制过去的误删。
截至 2026-08-02，PostgreSQL 18.4 是最新稳定 major 18 的当前 minor；14–18 仍处于官方支持期。生产实例应运行其所在 major 的当前 minor，而不是只因为 18 最新就强制跨 major 升级。版本状态见 PostgreSQL versioning policy 与 18.4 release notes。
最小生产基线
| 层 | 最先回答的问题 | 常见选择 |
|---|---|---|
| 数据库 | minor 更新、角色、TLS、参数、扩展如何管理？ | PostgreSQL 官方包或经过验证的镜像 |
| 连接 | 峰值应用并发会不会耗尽 backend？ | 应用连接池，必要时 PgBouncer |
| 恢复 | RPO/RTO 是多少，能否从平台外恢复？ | pgBackRest、WAL-G 或云平台备份 + 独立副本 |
| 可观测性 | 哪条 SQL、哪个等待事件、哪段日志解释故障？ | pg_stat_statements、JSON 日志、指标采集 |
| 变更 | DDL 锁、回填、回滚和兼容窗口如何验证？ | expand-and-contract、迁移检查、真实 PG 测试 |
| 可用性 | 独立故障域、仲裁和切换后数据边界是什么？ | 托管 HA、Patroni、CloudNativePG 或 Pigsty |
PgBouncer：不要默认选择 transaction pooling
PgBouncer 把大量客户端连接复用到较少的 PostgreSQL server connection。不要通过持续增大 max_connections 代替容量设计；每个 backend 都会占用内存和调度资源，还要给迁移、监控、备份、管理与复制保留连接。
| 模式 | server connection 归还时间 | 适用边界 |
|---|---|---|
session | 客户端断开 | 兼容性最高，适合依赖会话状态的应用 |
transaction | 事务结束 | Web/API 常用，但必须验证会话级特性 |
statement | 每条语句结束 | 不允许多语句事务，只适合非常受控的负载 |
transaction pooling 下，SQL 级 PREPARE、会话 advisory lock、LISTEN、带 WITH HOLD 的 cursor，以及许多依赖会话状态的做法不可用或受限。协议级 prepared statement 需要正确配置 max_prepared_statements 并验证驱动行为。完整矩阵见 PgBouncer feature map。
上线前至少验证：认证与 TLS、prepared statements、临时表、迁移工具、连接 reset、failover、事务重试，以及 ORM 是否把状态留在 session。
pgBackRest、WAL-G 与云平台备份
pgBackRest 支持 full/differential/incremental backup、并行传输、多 repository、WAL archive 与 PITR，适合自托管 PostgreSQL 的完整恢复链路。WAL-G 更偏对象存储工作流。二者都不能通过“安装完成”证明可恢复。
备份周期应由 RPO、WAL 生成量、恢复带宽、保留要求和实测 RTO 推导，而不是机械套用“每周全量、每日增量”。必须持续检查 archive gap、对象删除保护、加密密钥、跨账户或跨主机副本，并定期恢复到临时实例。
pg_dump 仍适合逻辑迁移、选择对象和小规模恢复，但它不能单独提供连续时间点恢复。详见 备份、恢复与 PITR。
Patroni、CloudNativePG 与 Pigsty 怎么选
| 环境 | 候选方案 | 采用前提 |
|---|---|---|
| 托管云数据库 | 服务商的跨可用区 HA | 核对区域、故障切换、PITR、扩展与平台外恢复限制 |
| 独立 VM / 裸机 | Patroni | 多个独立故障域、可靠 DCS、网络与存储运维能力 |
| 已有 Kubernetes 平台 | CloudNativePG | 团队已能运维 K8s、存储、网络和 Operator 升级 |
| 多集群自托管平台 | Pigsty | 接受 Ansible/VM 运维模型，并验证其集成组件与升级路径 |
CloudNativePG 的对象存储备份当前应评估 Barman Cloud Plugin，不要照搬已弃用的内置 object-store 配置。不要仅为了一个 PostgreSQL 实例引入 Kubernetes。
同一台机器的三个容器不是三个故障域
它们会同时受到主机断电、内核故障、存储损坏和网络中断影响。自动选主只在节点、存储和仲裁边界真实独立时改善可用性。
分阶段采用
生产基线
- 当前 minor、角色分离、TLS 与受控扩展；
- 连接预算，必要时部署并验证 PgBouncer；
- 独立保留的备份、连续 WAL/PITR 与恢复演练；
- SQL、指标、日志三层可观测性；
- 迁移前锁测试、超时、回退路径和业务验证。
条件采用
- 只有存在独立故障域和明确 RTO 时，才引入自动故障切换；
- 只有已有成熟 Kubernetes 运维时，才优先 CloudNativePG；
- 只有管理多个自托管集群的收益覆盖平台复杂度时，才引入 Pigsty；
- 只有真实工作负载需要时，才安装 pgvector、PostGIS、TimescaleDB 等扩展。
实验通道
PostgreSQL 19 Beta、较新的扩展和存储引擎应进入可丢弃的兼容性环境，而不是生产默认。将稳定版本测试与下一 major 测试拆成两条 CI 通道，见 安全迁移与零停机 Schema 变更。
Last updated on