8

现在的情况

因此，我将 WAL 归档设置到运行 Postgres 的数据记录计算机上的独立内部硬盘驱动器上。包含 WAL 存档的硬盘驱动器已满，我想删除所有 WAL 存档文件并将其存档到外部备份驱动器，包括初始基本备份。

目录结构如下：

D:/WALBACKUP/ 这是所有 WAL 文件的父文件夹（00000110000.CA00000004 等）

D:/WALBACKUP/BASEBACKUP/ 保存初始基本备份的 .tar

我当时的问题是：

  • 我可以安全地移动除当前 WAL 存档文件（000000000001.CA0000.. 等）之外的每个 WAL 文件，包括基本备份，并将它们移动到另一个硬盘。（注意数据库是实时的并且正在接收数据）

干杯！

4

4 回答 4

16

WAL 档案

您可以使用该命令从给定基本备份不需要的存档（ notpg_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……但它可能会破坏基于存档的备份、流式副本等。所以除非你必须，否则不要使用它。

于 2016-02-02T08:01:43.550 回答
7

WAL 文件是增量的，所以简单的答案是：你不能扔掉任何文件。解决方案是创建一个新的基础备份，然后可以删除所有以前的 WAL。

WAL 文件包含修改表的单独语句，因此如果您丢弃一些较旧的 WAL，则恢复过程将失败（它不会静默跳过丢失的 WAL 文件），因为无法可靠地恢复数据库的状态。您可以将 WAL 文件移动到其他位置而不会打乱 WAL 进程，但是如果您需要从过去的某个时间点恢复数据库，则必须从一个位置再次使所有 WAL 文件可用；如果您的磁盘空间不足，那么这可能意味着从您有足够空间存储基本备份和所有 WAL 文件的某个位置恢复。这里的主要问题是您是否能够以足够快的速度在事件发生后恢复完整的数据库。

另一个问题是，如果您无法确定需要纠正的问题发生的位置/时间，您唯一的选择是从基本备份开始，然后重播所有 WAL 文件。这个过程并不难，但是如果你有一个旧的基础备份和许多 WAL 文件要处理，这只会花费很多时间。

一般来说，适合您的情况的最佳方法是每 x 个月进行一次新的基本备份，并使用该基本备份收集 WAL。在每个新的基础备份之后，您可以删除旧的基础备份及其后续的 WAL，或者将它们移动到廉价的离线存储（DVD、磁带等）。如果发生重大事件，您可以从最近的基本备份和此后收集的相对较少的 WAL 文件中快速将数据库恢复到已知的正确状态。

于 2016-02-02T03:23:41.407 回答
6

我们寻求的一个解决方案是每晚执行pg_basebackup 。这将创建一个基础备份，稍后我们可以使用pg_archivecleanup清理该基础之前的所有“旧” WAL 文件，使用类似

"%POSTGRES_INSTALLDIR%\bin\pg_archivecleanup" -d %WAL_backup_dir% %newestBaseFile%

幸运的是，我们还没有恢复，但理论上它应该可以工作。

于 2017-01-19T07:38:46.500 回答
2

如果有人通过搜索如何在复制架构下安全清理 WAL 目录发现这一点，请考虑可能存在副本剩余的场景offline，在这种情况下，未使用的副本插槽等待副本重新上线，从而保持一个主数据库上有很多 WAL 档案。

replica_slot在我们的案例中，由于硬件故障，我们遇到了一个副本关闭的问题，我们不得不在主数据库上重新创建它，但忘记删除以前使用的副本。一旦我们清除了 PSQL 就摆脱了未使用的 WAL，一切都很好。

于 2020-02-13T01:20:38.477 回答