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

我们已建立的复制已损坏（停机期间“已删除请求的WAL段”）我们无法轻松地再次停止主服务器。

我们可以做

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

...当主postgresql仍处于满负荷状态时？（否则会pg_start_backup()导致

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

换句话说，会pg_start_backup()影响我们的应用程序吗？

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
• 复制快照卷中的数据

本质上，该想法是通过获取您可以随意复制的每个卷的时间点来减少数据库延迟其检查点的时间。

这是一个严重的事情，但是我必须在这里纠正一些问题。

先前的答案是：

您可以使用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不会为您完成。

就我在PostgreSQL上的经验而言，它是相对安全的操作，除非那一刻对性能产生重大影响。如果有，最好暂时暂停所有客户的写入。

在负载下将我的主服务器同步到从服务器时，我只有一个关键情况，这是由OOM Killer引起的（是的，您确实应该完全禁用数据库节点上的OOM Killer，那天我还不知道）。

因此，我已从每晚备份中恢复数据库，并将pg_archive目录中的所有WAL段提供给postgres进行重放（只需将它们复制到pg_xlog文件夹中）。一切都很好，但是停机当然是不可避免的。