PostgreSQL 14生产环境pg_wal存储过大及归档清理问题咨询

1. 手动清理归档文件夹是否正确？ #

• 直接删除归档文件夹内的WAL文件完全错误，会破坏归档链的完整性，直接导致时间点恢复（PITR）功能彻底失效，甚至可能干扰主库的归档逻辑。
• 使用pg_archivecleanup工具手动清理归档是合规操作，但需注意：
  • 它的逻辑是清理比指定LSN（日志序列号）更早的归档文件，执行前必须确认这些归档已无使用需求（比如已完成覆盖该归档周期的基础备份，或明确不需要更早的时间点恢复）。
  • 清理速度慢是正常现象：工具需要逐个校验WAL文件的LSN信息，归档文件数量越多，耗时越长，建议在业务低峰期执行。

2. 是否需要备份这些归档文件？ #

• 如果需要**时间点恢复（PITR）**能力：必须备份归档文件。归档是PITR的核心依赖，没有归档的话，只能恢复到最近一次全量备份的状态，无法恢复到备份之后的任意时间点。
• 如果完全不需要PITR，仅依赖全量备份：归档文件在PostgreSQL确认归档成功（可通过pg_stat_archiver的archived_count字段确认对应文件已归档）后，可以清理，但建议保留最近1-2个全量备份周期的归档，以防突发故障。

补充：为什么pg_wal空间未明显减少？ #

PostgreSQL只会在**检查点（Checkpoint）**完成后，清理已归档且不再需要的WAL文件：

• wal_keep_size=80GB是主库必须保留的最小WAL量，只有当pg_wal目录的总大小超过这个值，且旧WAL已完成归档时，才会触发清理。
• 可在业务低峰期手动触发检查点加速清理：

  CHECKPOINT;
  

  注意：手动触发检查点会产生一定IO负载，需避开业务高峰。

验证archive_cleanup_command是否生效 #

• 查看pg_stat_archiver结果：如果failed_count没有持续增长，说明命令在正常执行；若failed_count上升，需检查命令路径、权限是否正确。
• 查看PostgreSQL日志：搜索archive_cleanup_command关键词，确认是否有执行记录或错误信息。
• 确保配置格式正确，示例：

  archive_cleanup_command = 'pg_archivecleanup /your/archive/path %r'
  

  其中%r是PostgreSQL自动传入的、需要保留的最新WAL文件标识，工具会清理比这个文件更早的归档。

内容的提问来源于stack exchange，提问作者Vera Rusmalawati