PostgreSQL持续归档与时间点恢复(PITR)配置疑问：WAL文件重复变更

嘿，这个场景我在配置生产环境PITR的时候也碰到过，咱们先把问题拆解清楚，再一步步解决：

为什么会出现“同一个WAL文件多次变更”的假象？ #

首先得澄清：正常情况下，PostgreSQL的WAL文件一旦被切换出写状态（比如写满默认的16MB，或者手动执行pg_switch_wal()），就会变成只读文件，不会再被修改。你感觉到的“多次变更”，大概率是PostgreSQL在归档失败后自动重试同一个WAL文件的归档请求——PostgreSQL会持续尝试归档未标记为成功的WAL，直到归档命令返回成功为止。

当然也有极少数异常情况会导致WAL真的被修改，后面会讲到怎么排查。

如何满足官方要求的“拒绝覆盖归档文件”同时处理重试？ #

官方强调归档命令要拒绝覆盖，核心是防止不同实例的WAL文件互相覆盖，同时避免误操作损坏已归档的文件。我们可以通过以下方式实现安全的归档命令：

1. 编写带“不覆盖”逻辑的归档命令 #

用系统自带的工具实现“存在则跳过，不存在则复制”的逻辑，同时确保命令在跳过的时候返回成功（让PostgreSQL停止重试）：

• 用cp的话：

  archive_command = 'cp -n %p /your/archive/path/%f || exit 0'
  

  这里-n参数表示不覆盖已存在的文件，|| exit 0是关键——如果cp因为文件已存在而退出码非0，我们手动返回0，让PostgreSQL认为归档成功，避免无限重试。
• 用rsync的话：

  archive_command = 'rsync --ignore-existing %p /your/archive/path/%f || exit 0'
  

  --ignore-existing同样会跳过已存在的文件，效果和cp -n一致。

2. 确保归档目录的唯一性 #

绝对不要把多个PostgreSQL实例的归档目录混在一起！哪怕是同一台机器的不同实例，也一定要用独立的归档目录——WAL文件名虽然包含时间线和序列号，但如果实例重置过时间线，还是可能出现文件名冲突，这正是官方警告要规避的场景。

排查真·WAL文件被修改的异常情况 #

如果你通过校验（比如用md5sum对比数据库中的WAL文件和归档后的文件）发现内容真的变了，那就要排查以下问题：

• 检查wal_level配置：PITR要求wal_level至少设置为replica（旧版本是hot_standby），如果设为minimal，WAL会丢失很多恢复所需的信息，甚至可能出现异常写入。
• 检查归档目录的权限：确保只有PostgreSQL运行用户能读写归档目录，避免其他进程（比如管理员误操作、脚本错误）修改已归档的文件。
• 检查存储健康：如果归档目录所在的磁盘有IO错误、文件系统损坏，可能会导致文件内容异常，这时需要检查磁盘日志、修复文件系统。

额外的归档安全建议 #

• 定期校验归档文件的完整性：可以写个脚本，定期从数据库中导出WAL文件的校验和，和归档目录中的文件对比，确保没有损坏或篡改。
• 开启WAL校验和：在postgresql.conf中设置data_checksums = on（需要初始化数据库时开启），可以自动检测WAL文件的损坏。

内容的提问来源于stack exchange，提问作者Tᴀʀᴇǫ Mᴀʜᴍᴏᴏᴅ