WAL 与单机可靠性
PostgreSQL 使用 Write-Ahead Logging（WAL）保护数据页变化。修改后的数据页可以延迟写回，但描述该变化的 WAL 必须先到达持久化存储；崩溃恢复再从检查点开始重放 WAL，使文件回到一致状态。
提交与落盘
WAL 是物理变化记录，不是 SQL 审计日志。事务提交确认的严格程度还受 synchronous_commit 和同步复制配置影响；放宽确认条件可以降低延迟，但会扩大实例崩溃或主库故障时的丢失窗口。
检查点与崩溃恢复
检查点把检查点之前需要持久化的脏页推进到数据文件，并在 WAL 中记录一致的恢复起点。检查点越频繁，恢复扫描通常越短，但写入峰值和 WAL Full Page Image 开销可能增加；间隔过大则需要更多 WAL 空间并延长恢复。
实例异常停止后的恢复流程大致为：
text
读取控制信息
→ 定位最近有效检查点
→ 从对应 WAL 位置开始重放
→ 恢复事务与数据页一致状态
→ 开放连接WAL 能应对进程或操作系统崩溃，不能在数据文件与所需 WAL 同时丢失时凭空恢复数据。
归档、基础备份与 PITR
pg_wal 中的 WAL 段会被循环复用。连续归档把完成的 WAL 段复制到独立归档位置；基础备份提供完整数据文件起点，两者组合可以执行 Point-in-Time Recovery（PITR）。
| 材料 | 作用 |
|---|---|
| Base Backup | 提供某一恢复区间的物理文件基线 |
| Archived WAL | 把基线推进到目标时间或恢复终点 |
| Timeline History | 描述提升和恢复产生的时间线分支 |
| 配置与密钥备份 | 补充 WAL 不记录的外部配置和访问材料 |
只保存 Base Backup 会损失备份结束之后的变化；只保存 WAL 又缺少可开始重放的数据基线。归档链中缺失一个必需 WAL 段，也可能使恢复无法越过缺口。
单机故障边界
| 故障 | 单机机制 | 额外措施 |
|---|---|---|
| Backend Process 异常 | 主进程会终止相关进程并执行恢复 | 排查触发原因和未完成请求 |
| 实例或操作系统崩溃 | WAL 崩溃恢复 | 可靠持久化存储和启动检查 |
| 数据盘损坏 | 不能依赖本机自动恢复 | 独立 Base Backup、连续归档和恢复演练 |
| 误删、误更新 | 不会自动撤销已提交事务 | PITR、审计或业务补偿 |
| 主机永久故障 | 单机无法自动接管 | 备用节点、故障检测和流量切换 |
| 机房故障 | 单故障域无法覆盖 | 异地备份或跨故障域复制 |
备份与归档若全部位于数据库所在主机或同一存储，只能覆盖有限故障。可靠性应以可验证的 RPO、RTO 和恢复演练衡量，而不是以任务显示“备份成功”衡量。
运行监控
pg_wal、归档目标和复制槽保留 WAL 的增长速度。- Checkpoint 频率、写入耗时和后台写入压力。
- 归档失败次数与最近成功归档时间。
- 数据校验、存储 I/O 错误和文件系统剩余空间。
- Base Backup、WAL 连续性及定期恢复演练结果。
复制槽可以防止所需 WAL 被回收，但消费者停止时也可能无限保留 WAL，最终占满磁盘。它是保留机制，不是容量保护机制。