云 PG 生产选型清单
用可验证问题和演练替代功能表打勾
1. 兼容性清单
- PostgreSQL 大版本、次版本补丁节奏和停止支持日期是什么？
pg_extension中需要的扩展及版本是否都可用？升级是自动、手工还是需要迁移？- 哪些参数不可改？是否允许
shared_preload_libraries？ - 是否支持逻辑复制、复制槽、FDW、事件触发器和所需认证方式？
- 系统目录、统计视图和超级用户操作有哪些替代接口？
- 驱动、ORM、迁移工具和备份工具是否通过真实流水线测试？
把检查结果保存为机器可读清单，绑定服务 SKU、区域、引擎版本和核对日期。
2. 可用性与恢复
| 测试 | 通过条件示例 |
|---|---|
| 强制主备切换 | 客户端在预算内重连；事务失败以可识别 SQLSTATE 返回；没有静默部分成功 |
| PITR | 恢复到指定时间的新实例；校验业务行数、约束、角色和扩展；实测 RTO |
| 误删恢复 | 明确整实例、整库、单表各自的恢复路径和耗时 |
| 区域故障 | DNS、密钥、对象存储备份和应用计算不与数据库同故障域 |
| 备份导出 | 能在厂商账号之外恢复一份可用副本 |
自动故障转移会断连接
应用仍需设置连接超时、事务级重试和幂等键。不要重放一个已经可能提交成功的写操作，除非可以用业务幂等键确认结果。
3. 连接与弹性
计算每个应用副本、后台任务、迁移工具、BI 和 Agent 的连接上限。对 serverless/Agent 流量优先使用受控池，但要确认：
- transaction pooling 是否与 session state、临时表、LISTEN/NOTIFY 或 prepared statements 兼容；
- 缩容、休眠、故障切换时连接字符串和 TLS 证书是否变化；
statement_timeout、idle_in_transaction_session_timeout和客户端超时谁先触发；- 突发请求是否在应用层排队，而不是把连接风暴直接传给 PostgreSQL。
4. 成本模型
除计算与存储外，至少估算 IOPS、备份、跨区流量、只读副本、日志、监控、代理、PITR、快照导出和支持计划。AI 工作负载还应单列 embedding、索引重建、向量存储和检索候选重排成本。
5. 可迁移性
每季度或大版本升级前执行一次：
pg_dump --format=custom --no-owner --no-acl "$DATABASE_URL" > app.dump
createdb portability_restore
pg_restore --exit-on-error --no-owner --no-acl \
--dbname=portability_restore app.dump这只是逻辑可迁移性检查，不替代平台 PITR。恢复后还要核对 extension、role/grant、large object、sequence、行数、约束、关键查询结果和执行计划。
上线证据包
- 服务/区域/SKU/引擎/扩展版本清单；
- RPO、RTO、连接预算和容量模型；
- failover、PITR、误删与平台外恢复报告；
- 加密、网络、角色、RLS 与密钥轮换记录；
- 版本升级、扩展升级和厂商退出 runbook；
- 基准负载下的延迟、错误、WAL、vacuum、存储与成本数据。
Last updated on