如何为*仅*托管开发或测试数据库的集群配置 WAL 归档？

Question

我有一个项目的开发和测试数据库，即我用来在本地运行我的项目或运行测试的数据库。 它们都在同一个集群中（“实例”——我来自雷德蒙德）。

请注意，我的本地集群与托管生产数据库的集群不同。

关于归档 WAL 文件，我应该如何配置这些数据库？

我希望能够通过从基本备份恢复并运行种子数据脚本来“构建”或“重建”这些数据库中的任何一个。

但是我应该如何配置数据库或集群来归档 WAL 文件？ 我知道如果我想恢复数据库，我需要它们。 我认为这不太可能（因为我什至不知道“WAL”或它们的文件，或者它们可能被同一集群中的所有数据库共享，这似乎来自 Microsoft SQL 服务器，这看起来很奇怪和可怕。）

如果我重建其中一个数据库，我应该删除自基本备份以来的 WAL 文件——我该怎么做？

但我也不想担心 WAL 文件的大小会无限增长。 我不想为了节省空间而被迫重建。 我能做些什么来防止这种情况发生？

我的本地集群只包含一个用于我的项目的开发和测试数据库，即从这些数据库之一丢失数据是（或应该）没什么大不了的。 即使必须重新创建集群本身和两个数据库，如果将两个数据库恢复到本地开发和测试的“工作”状态比其他方式更容易的话，这也不是问题。

换句话说，我不关心这两个数据库中的数据。 我将确保——与 WAL 归档分开——我可以将任一数据库恢复到足以满足我需求的 state。

另外，我想记录（例如在代码中）如何配置我的本地集群和两个数据库，以便同一项目的其他开发人员可以为他们的本地集群使用相同的设置。 这些集群都不同于托管生产数据库的集群。

Answer 1

通常建议您让第三方应用程序为您处理，而不是尝试手动管理您的 WAL 文件。 有多种选择，但pg_backrest是最流行的开源产品。

Answer 2

每个数据库实例写入其 WAL stream，切成 16MB 的段。

其他所有关系数据库都做同样的事情，甚至 Microsoft SQL 服务器（不同之处在于这些文件的名称和组织）。

WAL 包含重放事务所需的物理信息。 将其想象为如下信息：“在文件 x 中，块 2734，在偏移量 543 处更改 24 个字节，如下所示：...”

使用基本备份和此信息，您可以在基本备份结束后恢复数据库生命周期中的任何给定时间点。

每个 PostgreSQL 集群都会写入自己的“WAL 流”。 这些文件以从不重复的长而奇怪的十六进制数字命名，因此不存在集群的后续 WAL 段与同一集群的早期 WAL 段发生冲突的危险。

您必须确保将 WAL 存档到另一台机器，否则该练习将毫无用处。 如果您在同一台机器上有多个集群，请确保将它们归档到不同的目录（或一般位置），因为不同集群的 WAL 段的名称会发生冲突。

关于保留：您希望将备份保留一段时间。 一旦你摆脱了一个基本备份，你也可以摆脱该基本备份之前的所有 WAL 段。 有一个pg_archivecleanup可执行文件可以帮助您摆脱所有比给定基本备份更旧的存档 WAL 段。

Answer 3

我希望能够通过从基本备份恢复并运行种子数据脚本来“构建”或“重建”这些数据库中的任何一个。

basebackup 来自哪里？ 如果您正在恢复 PROD 基础备份并在其上运行种子脚本，那么您根本不需要在 test/dev 上进行 WAL 归档。 但是你得到的将是 PROD 的克隆，这意味着它不会在同一实例中具有用于测试和开发的不同数据库，因为（可能）PROD 没有。

如果基本备份来自其他地方，您必须描述它是什么。 这将决定您的 WAL 需求。

尝试运行一个同时包含测试和开发的实例对我来说似乎是一种虚假的经济。 只需运行两个实例。

设置archive_mode=off将完全禁用 wal 存档。 在 pg_wal 或 pg_xlog 目录中仍然会有“活动的”WAL 文件，但是这些文件会在每个检查点之后自动删除/回收——除了控制检查点发生的频率（并确保你周围没有任何复制槽）。 WAL 存档和实时 WAL 文件是不同的东西。 实时 WAL 文件是强制性的，需要自动从电源故障等情况中恢复。 WAL 存档可能需要手动从硬盘崩溃或服务器完全破坏中恢复，并且在开发/测试中可能根本不需要。