关于延迟备库的WAL恢复原理及无wal_sender/wal_receiver进程时WAL获取方式的技术问询

咱们来拆解你关于PostgreSQL延迟备库的两个问题——这些都是搭建灾备架构时经常遇到的细节点，很有价值。

1. 延迟备库是如何实现WAL恢复的？ #

延迟备库本质上是基于PostgreSQL标准的WAL恢复流程，只是多了一层延迟触发应用的逻辑，核心步骤如下：

• 备库启动时进入恢复模式，读取配置（PostgreSQL 12+在postgresql.conf，旧版本在recovery.conf）中的recovery_min_apply_delay参数（比如'1h'表示延迟1小时）。
• 备库通过wal_receiver进程从主库流式接收WAL，或者从归档源拉取WAL文件，先将这些WAL写入本地的pg_wal目录暂存。
• 负责恢复的startup进程会逐一检查每个WAL记录的提交时间：只有当当前系统时间 - WAL记录的提交时间 ≥ 配置的延迟时长时，才会应用这条WAL记录更新备库数据。
• 这里要划重点：延迟是针对WAL记录的提交时间而非接收时间，这能保证备库的数据始终严格比主库晚指定时长，不受WAL传输耗时的影响。

2. 延迟备库恢复WAL采用的机制是什么？流式复制进程不存在时的行为？ #

延迟备库的WAL恢复机制核心还是PostgreSQL的标准恢复流程，只是叠加了延迟应用的规则，它支持两种WAL获取方式：

• 流式复制模式：和普通备库一致，通过主库的wal_sender和备库的wal_receiver进程实时传输WAL。此时备库会先缓存接收到的WAL，等满足延迟条件后再应用。
• 归档恢复模式：当流式复制进程（wal_sender/wal_receiver）因为网络中断、主库故障等原因不存在时，备库会自动切换到从归档源拉取WAL的模式。

针对流式进程失效的场景，具体行为如下：

• 备库会先检查本地已有的WAL位置，然后通过配置的restore_command命令，从指定的归档源（比如Barman、本地归档目录）依次拉取缺失的WAL文件。
• 如果配置了Barman作为归档存储，restore_command通常会指向Barman的WAL拉取脚本，比如barman get-wal --server=my-db-server %f，备库会自动通过这个命令从Barman获取所需的WAL文件。
• 不管是流式还是归档模式，延迟应用的逻辑始终由startup进程控制——它会严格按照WAL记录的提交时间来判断是否满足延迟要求，不会因为获取方式的改变而打乱延迟规则。

内容的提问来源于stack exchange，提问作者Fabrice Chapuis