PostgreSQL使用Barman pg_recievewal时旧WAL未清理问题咨询

关于pg_recievewal是否需要开启归档的理解 #

你的理解部分正确：使用pg_recievewal搭配PostgreSQL复制槽，确实可以替代传统的archive_command实现WAL流式传输，无需依赖本地归档再推送的模式。但这并不代表完全不需要Barman的归档逻辑——Barman必须完成WAL的“安全归档确认”，才能让PostgreSQL触发旧WAL的清理。

旧WAL堆积的核心原因 #

结合你的场景，主要是以下两点：

1. Barman 2.7的pg_recievewal流式接收未触发清理确认
   单纯用pg_recievewal接收WAL时，Barman仅完成了WAL的传输与存储，但未主动向PostgreSQL发送“该WAL已安全归档”的信号。PostgreSQL的WAL清理逻辑，除了依赖复制槽的restart_lsn，还需要确认WAL已被可靠归档（流式备份场景下此逻辑更严格）。启用barman-wal-archive后，Barman执行完整的归档验证流程，主动告知PostgreSQL哪些WAL可清理，从而触发自动清理。

2. 复制槽LSN更新与清理触发的延迟
   虽然你查询到restart_lsn与当前WAL LSN一致，但PostgreSQL的WAL清理是在checkpoint阶段触发的。如果checkpoint未及时执行，或pg_recievewal进程异常后未正确同步LSN状态，会导致旧WAL暂时无法被清理。而barman-wal-archive会强制同步WAL状态，加速清理动作。

实用建议 #

• 检查Barman配置，确保streaming_archiver = on（Barman 2.7默认可能未开启），该参数会让Barman在接收WAL后自动完成归档确认，无需手动执行barman-wal-archive。
• 定期监控pg_stat_replication和pg_replication_slots，确认pg_recievewal连接稳定，restart_lsn持续更新。

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