PostgreSQL 配置 WAL 日志归档用于 PITR 恢复，需要在 postgresql.conf 中启用 archive_mode 并设置 archive_command，同时配合基础备份使用。

命令速用版

以下配置片段可直接用于 PostgreSQL 12 及以上版本，修改 postgresql.conf 后需重载配置。

archive_mode = on
archive_command = 'cp %p /path/to/archive/%f'
wal_level = replica

执行基础备份命令：

pg_basebackup -D /path/to/backup -Ft -z -Xs -P

为什么会这样

WAL 日志记录数据库所有变更，归档保存历史日志以便重放。

PostgreSQL 使用预写式日志（WAL）记录数据修改，默认情况下日志写满后会循环覆盖。开启归档模式后，数据库会在 WAL 段文件填满时调用 archive_command 将其复制到安全存储。PITR 恢复依赖基础备份还原数据基线，再通过重放归档日志将数据推进到指定时间点。

分步处理

第一步：修改配置文件 postgresql.conf。

设置 wal_level 为 replica 或 logical，启用 archive_mode，并定义 archive_command 脚本路径。确保归档目录存在且 postgres 用户有写入权限。

第二步：重载数据库配置。

执行 SELECT pg_reload_conf(); 或 pg_ctl reload，使归档设置生效而不重启服务。

第三步：执行基础备份。

使用 pg_basebackup 工具创建物理备份，这是 PITR 恢复的起点，备份期间会自动触发 WAL 切换。

第四步：配置恢复信号文件（PostgreSQL 12+）。

恢复时在数据目录创建 recovery.signal 文件，并在 postgresql.auto.conf 中设置 restore_command 指向归档路径。

怎么验证是否生效

查询 pg_stat_archiver 系统视图确认归档状态。

执行 SQL：SELECT * FROM pg_stat_archiver; 检查 archived_count 是否递增，last_failed_time 是否为空。同时检查归档目录下是否有新的 WAL 文件生成，文件名通常包含时间线和日志序列号。

常见坑

archive_command 失败会导致数据库暂停。

如果归档脚本返回非零退出码，PostgreSQL 会不断重试该 WAL 文件，可能导致磁盘写满或数据库阻塞。建议在脚本中做好错误处理和日志记录。

PostgreSQL 12 前后恢复配置差异大。

12 版本之前使用 recovery.conf，12 及之后使用 postgresql.auto.conf 配合信号文件。混用配置会导致恢复失败。

归档目录空间不足。

WAL 日志会持续产生，若未配置清理策略或空间监控，归档目录可能占满磁盘导致主库停摆。

常见问题

只开启归档不做基础备份能恢复吗？

不能。归档日志只能重放变更，没有基础备份提供的数据基线，归档日志无法独立还原数据库。

如何停止 WAL 归档？

将 postgresql.conf 中的 archive_mode 设置为 off 并重载配置，或者将 archive_command 设置为空字符串。

归档日志可以删除吗？

可以，但需确认不再需要基于该时间点恢复。通常配合 pg_archivecleanup 工具根据最新备份清理旧日志。

参考来源

PostgreSQL Documentation: WAL Archiving

https://www.postgresql.org/docs/current/wal-archiving.html

PostgreSQL Documentation: Continuous Archiving and Point-in-Time Recovery (PITR)

https://www.postgresql.org/docs/current/continuous-archiving.html