现状
所以我在运行Postgres的数据记录计算机上将WAL归档设置为独立的内部硬盘。包含WAL档案的硬盘正在填满，我想将所有WAL档案文件（包括初始基本备份）删除并归档到外部备份驱动器。
目录结构如下：
D：/ WALBACKUP /是所有WAL文件的父文件夹（00000110000.CA00000004等）
D：/ WALBACKUP / BASEBACKUP /，它包含初始基本备份的.tar
我的问题是：
喝彩！
答案 0 :(得分：13)
您可以使用pg_archivecleanup命令从存档中删除WAL（不 pg_xlog），这不是给定基本备份所必需的。
一般情况下，我建议使用PgBarman或类似工具自动执行基本备份和WAL保留。它更容易，更不容易出错。
pg_xlog 永远不要手动从pg_xlog删除WAL。如果你有太多的WAL，那么：
wal_keep_segments设置正在保持WAL; archive_mode并设置了archive_command但它无法正常工作（请查看日志）; checkpoint_segments高得离谱，所以你只是产生太多的WAL;或pg_replication_slots视图），它阻止了WAL的移除。您应该解决导致WAL被保留的问题。如果在更改设置后似乎没有发生任何操作，请运行手动CHECKPOINT命令。
如果你有一台离线服务器并且需要删除WAL才能启动它，你可以使用pg_archivecleanup。它知道如何仅删除服务器不需要的WAL ...但它可能会破坏基于存档的备份，流式副本等。所以除非你必须，否则不要使用它。
答案 1 :(得分：7)
WAL文件是增量的，所以简单的答案是：你不能抛出任何文件。解决方案是进行新的基本备份，然后删除所有以前的WAL。
WAL文件包含修改表的单个语句，因此如果您丢弃一些较旧的WAL，则恢复过程将失败（它不会以静默方式跳过丢失的WAL文件），因为无法可靠地恢复数据库的状态。您可以将WAL文件移动到其他位置而不会破坏WAL进程，但如果您需要从过去的某个时间点恢复数据库，则必须从单个位置再次使所有WAL文件可用;如果你的磁盘空间不足那么这可能意味着从你有足够空间存储基本备份和所有WAL文件的某个位置恢复。这里的主要问题是如果你能够在事件发生后足够快地恢复完整的数据库。
另一个问题是，如果您无法确定需要纠正的问题发生的位置/时间，则唯一的选择是从基本备份开始，然后重播所有WAL文件。这个过程并不困难，但如果你有一个旧的基本备份和许多要处理的WAL文件，这只需要很多时间。
对于您的案例，最佳方法是每x个月进行一次新的基本备份，并使用该基本备份收集WAL。在每次新的基本备份之后，您可以删除旧的基本备份及其后续的WAL，或将它们移动到廉价的离线存储（DVD，磁带等）。在发生重大事件的情况下，您可以从最近的基本备份和从那时起收集的相对较少的WAL文件快速将数据库恢复到已知的正确状态。
答案 2 :(得分：5)
我们采用的解决方案是每晚执行pg_basebackup。这将创建一个基本备份，稍后我们可以使用pg_archivecleanup来清理所有＆＃34; old＆＃34;使用类似
之类的东西之前的WAL文件"%POSTGRES_INSTALLDIR%\bin\pg_archivecleanup" -d %WAL_backup_dir% %newestBaseFile%
幸运的是，我们从来没有恢复过，但它应该在理论上起作用。
答案 3 :(得分：1)
如果有人通过搜索如何安全地清理复制体系结构下的WAL目录发现了此情况，请考虑以下情形：offline副本中可能有剩余，在这种情况下，未使用的副本插槽正在等待副本重新上线，从而在Master DB上保留了大量WAL档案。
在我们的案例中，由于硬件故障，副本出现了问题，我们不得不在主数据库上连同它的replica_slot重新创建它，却忘记摆脱以前使用过的副本。一旦我们弄清楚了，PSQL摆脱了未使用的WAL，一切都很好。