复制与高可用
PostgreSQL 内核提供 WAL 复制、恢复、提升和逻辑复制能力，但不会独立完成全部高可用编排。故障检测、领导者选举、防止双主、连接入口切换以及旧主隔离，通常由外部组件和运维流程承担。
物理复制
物理复制传输 WAL，并在 Standby 上按块级变化重放。主备需要保持系统版本和底层物理格式兼容，备库是整个 database cluster 的副本，不能原生只复制其中几张表。
| 方式 | 特点 | 边界 |
|---|---|---|
| WAL 文件归档 | 按完成的 WAL 段传输 | 延迟受 WAL 段切换影响 |
| Streaming Replication | WAL 生成后持续流式传输 | 默认异步，网络中断时需要保留足够 WAL |
| Hot Standby | 恢复期间允许只读查询 | 查询可能与 WAL 重放冲突，读延迟不固定 |
| Cascading Replication | Standby 向下游发送 WAL | 降低主库连接压力，但增加链路与延迟层次 |
Replication Slot 能防止主库过早删除备库仍需要的 WAL。备库永久离线或 Slot 消费停滞时，WAL 会持续占用主库磁盘，因此必须监控 Slot 的消费位置和保留量。
同步级别与事务确认
流复制默认异步。同步复制可以要求事务提交等待指定 Standby 达到某个阶段，降低主库故障时的数据丢失，但把网络与备库状态带入主事务延迟。
| 等待层次 | 含义 | 主要权衡 |
|---|---|---|
| 本地 WAL 持久化 | 主库确认本地 WAL | 主库永久损坏时可能丢失尚未复制事务 |
| Remote Write | 备库操作系统已接收并写入 | 不一定已经持久化或重放 |
| Remote Flush | 备库已持久化 WAL | 数据保护较强，提交受网络和备库磁盘影响 |
| Remote Apply | 备库已重放，查询可见 | 一致读取更直接，提交延迟最高 |
RPO 不能仅凭“同步复制”判断，还取决于同步 Standby 的数量、确认级别、故障时是否允许降级，以及切换节点是否拥有最新时间线。
逻辑复制
逻辑复制对 WAL 进行逻辑解码，以 Publication 和 Subscription 复制选定表的变化。它适合选择性复制、跨大版本迁移和数据分发，但不是物理备库的直接替代。
| 维度 | 物理复制 | 逻辑复制 |
|---|---|---|
| 粒度 | 整个 database cluster | 表级发布 |
| 数据形态 | 块级 WAL 重放 | 逻辑行变化 |
| 版本约束 | 物理格式需兼容 | 更适合跨版本迁移，仍需验证兼容性 |
| DDL | 物理变化随 WAL 重放 | 通常需要单独同步 Schema 变更 |
| 冲突 | Standby 不接受普通写入 | Subscriber 的额外写入可能产生冲突 |
| 用途 | 高可用、容灾、只读副本 | 数据分发、升级迁移、局部复制 |
逻辑复制依赖 Replica Identity 定位 UPDATE 和 DELETE 的目标行。序列、Large Object、DDL 和未发布对象等内容需要按实际版本与方案单独处理。
故障切换闭环
- 判断 Primary 是否真的不可服务，避免网络分区误判。
- 选择 WAL 最完整、满足一致性要求的 Standby。
- 隔离旧 Primary，防止两个节点同时接受写入。
- Promote 新 Primary，并切换连接入口。
- 验证 Timeline、复制槽、应用写入和数据一致性。
- 用
pg_rewind或重新做 Base Backup 将旧主恢复为 Standby。
PostgreSQL 自身不提供完整的故障检测和通知系统。仅搭建 Streaming Replication 不等于已经具备自动高可用；管理器、代理、共识存储和 Fencing 需要形成经过演练的整体。