PostgreSQL：我可以在负载下运行的实时数据库上执行 pg_start_backup() 吗？

Question

我们建立的复制已中断（在停机期间“请求的 WAL 段已被删除”）我们不能轻易地再次停止主服务器。

我们可以吗

1. pg_start_backup(),
2. rsync ${PGDATA}/ 主人对奴隶，
3. pg_stop_backup()

...而master postgresql 仍处于满负荷状态？（或者会pg_start_backup()导致

• 表锁，
• I/O 块，
• 不一致，
• 火警，
• 数据库响应缓慢

换句话说，会不会pg_start_backup()影响我们的申请？

Answer 1

pg_start_backup正如 dezso 所说，将执行检查点。这确实有影响，但您的数据库无论如何都会定期执行检查点，并且必须这样做才能正常运行，因此它们对您来说显然不是问题。早期检查点意味着积累的数据较少，这意味着如果有任何检查点pg_start_backup的影响将低于正常情况。

您需要担心的是 rsync 或等效pg_basebackup步骤。由于它是顺序的，因此读取 I/O 不会太糟糕，但它仍然可能会严重损害您的数据库的 I/O 性能，并且它还倾向于将热数据从 RAM 缓存中推出，以支持较少的数据- 使用的数据，导致缓存抖动，因为更需要的数据随后被读回。

您可以使用nice和ionice来帮助限制 I/O 影响（但不是缓存影响）；然而，这样做是有代价的。备份将需要更长的时间，并且在您完成备份并运行pg_stop_backup系统之前 - 据我所知 - 累积 WAL 它无法删除，在备份运行结束时为 BIG 检查点累积检查点债务，并且正在累积表和索引膨胀，因为它无法清理死行。所以你真的不能承受永远的备份，特别是如果你有非常高的流失表。

最后，很难说您是否可以在您的环境中安全地使用pg_start_backup和pg_stop_backup进行热备份。大多数人都可以，但是如果您接近硬件的极限，时间要求很紧，无法承受停顿的风险，并且拥有非常高的流失表以及非常大的表，那么这可能会很麻烦.

不幸的是，您几乎需要对其进行测试并查看。

如果可以，可能值得发布一个CHECKPOINT然后对数据库所在的卷进行原子快照，而不是使用 LVM、您的 SAN 工具、EBS 或您正在使用的任何东西。如果您能做到这一点，您就可以在闲暇时复制快照。这种方式不适用于PITR/热备/热备的基础备份，但是对于静态备份副本来说是非常好的，并且对系统的影响要小得多。但是，只有当您的快照是原子的并且您的整个数据库（包括 WAL）都在一个卷上时，您才能这样做。

我还没有研究过的一种可能性是将这两种方法结合起来。我突然想到一个可能（未经测试，可能是错误和不安全的，我还不知道）：

• pg_start_backup
• 触发所有表空间、主数据目录和 xlog 卷的快照
• pg_stop_backup
• 将 WAL 复制到最终存档 pg_stop_backup
• 从快照卷中复制数据

从本质上讲，这个想法是通过获取您可以在闲暇时复制的每个卷的时间点来减少数据库必须延迟检查点的时间。

Answer 2

这是一个坟墓挖掘，但我必须在这里纠正一些事情。

之前的回答是这样说的：

您可以使用 nice 和 ionice 来帮助限制 I/O 影响（但不是缓存影响）；然而，这样做是有代价的。备份将需要更长的时间，并且在您完成备份并运行 pg_stop_backup 之前，您的系统是 - 据我所知 - 累积 WAL 它无法删除，在备份运行结束时为 BIG 检查点累积检查点债务，并且正在累积表和索引膨胀，因为它无法清理死行。所以你真的不能承受永远的备份，特别是如果你有非常高的流失表。

这不是真的。系统将保留您的配置中声明的 WAL 数量（参见在线文档）。所以基本上，之间的较高值：

• (2 + checkpoint_completion_ratio) * checkpoint_segments + 1
• wal_keep_segments

让我们想象一下这个案例：

• 您的备份需要很长时间，因为有数百个演出要复制
• 你有一个小的 WAL 保留（例如，checkpoint_segments 到 3）
• 你没有设置 WAL 归档

然后在启动“pg_start_backup()”之后，您的 WAL 文件将在您的备份期间旋转。备份完成后，您将尝试在另一个数据库引擎上恢复它。启动时的引擎至少会要求您发出“pg_start_backup()”时生成的 WAL 文件。

pg_start_backup 
-----------------
B/D0020F18
(1 row)

在您提供 WAL 文件“0000000x0000000B000000D0”（其中 x 是您的TimelineID）之前，数据库不会接受启动。这个 WAL 文件是系统启动的最低要求。当然，只有这个文件，您将丢失数据，因为其余数据位于您没有的 WAL 文件中，但至少，您将拥有一个可以工作的数据库引擎。

所以要么你必须做 WAL 归档，要么你必须自己保存所需的 WAL 文件，但 Postgresql 不会为你做。