Imran Zaheer：PostgreSQL 恢复机制内幕
内容提要
PostgreSQL 通过预写日志（WAL）实现崩溃恢复：先写日志再写数据文件，故障时重放 WAL 恢复一致状态。恢复流程包括初始化、判断恢复类型（崩溃恢复、归档恢复或备库恢复）并执行重做直至一致点。该机制同时支撑 PITR、复制和热备，保障 ACID 持久性。
延伸解读
恢复类型的选择逻辑
PostgreSQL 在恢复初始化阶段通过检查控制文件、备份标签文件以及 recovery.signal 和 standby.signal 等信号文件来决定恢复类型。如果 standby.signal 存在，则优先进入备库恢复；如果两者都不存在，则不会进入归档恢复。这一判断过程决定了后续是执行崩溃恢复还是归档恢复，并设置 InRecovery 标志。理解这一选择逻辑有助于诊断恢复行为是否符合预期。
一致状态因恢复类型而异
一致状态是恢复停止的关键点，但不同恢复类型下其定义不同。崩溃恢复中，一致状态指重放所有可用 WAL 后数据库可接受读写；归档恢复（如 PITR）中，一致状态还受 recovery_target_name、recovery_target_inclusive 等参数控制，可能提前停止；备库恢复中，一致状态允许只读查询，同时 WAL 重放继续。因此，恢复时长和停止点需根据具体场景和参数配置来理解。
WAL 读取与预取优化
恢复过程中需要高效读取 WAL 记录，PostgreSQL 通过 xlogprefetcher 预取记录来保持恢复流畅。文章提到可调整 xlogprefetcher、wal_decode_buffer_size、wal_buffers 和 recovery_prefetch 等参数来改善预取效果。此外，恢复模块有专门的 WAL 段文件读取实现，如 read_local_xlog_page_no_wait、XLogPageRead 等，扩展开发中常使用 read_local_xlog_page_no_wait。这些细
Q&A
PostgreSQL 的崩溃恢复机制是如何工作的？
PostgreSQL 通过预写日志（WAL）实现崩溃恢复：在将更改应用到数据文件之前，先将所有更改记录到 WAL 中。发生故障时，系统会重放 WAL 记录，将数据库恢复到一致状态，确保已提交的数据不丢失。
PostgreSQL 恢复时如何判断应该执行哪种类型的恢复？
恢复初始化阶段会检查控制文件、备份标签文件以及恢复信号文件（recovery.signal 和 standby.signal）。如果存在 standby.signal，则优先进入备库恢复；如果存在 recovery.signal，则进入归档恢复；如果两者都不存在，则不会进入归档恢复，可能执行崩溃恢复。根据这些检查结果，设置 InRecovery 标志。
PostgreSQL 中一致状态是如何定义的？不同类型的恢复有何不同？
一致状态是指所有数据块都代表有效且正确的数据库状态，所有必需的 WAL 记录都已重放，反映了截至该时刻的所有已提交事务。在崩溃恢复中，一致性在重放足够的 WAL 以安全完成中断操作后达到；在归档恢复（包括 PITR）中，一致性还受恢复目标参数（如 recovery_target_name、recovery_target_inclusive）影响，可能提前停止；在备库恢复中，一致性点允许只读查询，同时 WAL 重放继续在后台进行。
PostgreSQL 恢复过程中如何高效读取 WAL 文件？
PostgreSQL 使用 xlogprefetcher 来提前读取和预取 WAL 记录，以保持恢复流程顺畅。可以通过调整参数如 xlogprefetcher、wal_decode_buffer_size、wal_buffers 和 recovery_prefetch 来优化预取，从而提升恢复性能。
PostgreSQL 的恢复机制支持哪些高级功能？
PostgreSQL 的恢复机制不仅支持崩溃恢复，还支撑了时间点恢复（PITR）、复制和热备。这些功能都基于相同的核心机制：重放 WAL 记录直到达到一致状态。
在 PostgreSQL 备库恢复中，哪些参数会影响一致性和查询行为？
在备库恢复中，参数 max_standby_streaming_delay、max_standby_archive_delay、hot_standby 和 recovery_min_apply_delay 会影响一致性和查询行为。这些参数控制 WAL 重放延迟和只读查询的允许程度。
