备份 postgresql 数据库的最佳方法答案

【问题标题】：Most optimal way to backup postgresql database备份 postgresql 数据库的最佳方法
【发布时间】：2020-06-11 15:58:07
【问题描述】：

我有一个中等流量的中型数据库（postgresql 9.6）。该数据库位于虚拟服务器上，被描述为具有 4 个 CPU 内核和 8192MB 内存。

目前我每隔一小时备份一次服务器，在服务器上使用 pg_dump。如您所料，此过程可能需要一些时间，但提出此问题的原因是该过程会占用大量 CPU，这意味着我们经常会在一天中看到性能下降。

我们的 pg_dump 是这样运行的，为每个表单独生成一个转储，以及所有表的单个转储：

for table in $(psql -d "XXX" -t -c "SELECT table_name FROM information_schema.tables WHERE table_type = 'BASE TABLE' AND table_schema = 'public'");
    do pg_dump -Fc -t $table -d "XXX" > $1/$table.bak;
done;
pg_dump -Fc -d "XXX" > $1/all_tables.bak;

所以我的问题是：如何优化备份过程？理想情况下，我正在寻找 CPU 方面的最佳进程。

到目前为止，我已经尝试了一些事情，例如尝试将转储进程卸载到另一台服务器，但我发现结果有限......

任何建议将不胜感激！

【问题讨论】：

我不得不问，你为什么要每小时备份一次数据库？另外，您为什么要备份每张桌子两次？每天晚上一次怎么样？
为什么要按表转储？当您使用自定义格式时，您可以轻松地从该转储中恢复单个表。
并不是说这不是真正的“备份”而是转储。如果你想要真正的备份，使用 WAL 归档或 pgBackRest 或 barman 之类的工具（对系统的影响会小很多）
我同意每小时转储可能有点过分，但数据库在不断变化，因此过去定期备份以最大程度地减少损失是有用的......但是我同意这或许应该进一步考虑。至于每个表的转储，这是因为如果您尝试使用 -t 和 pg_restore，您不会完全恢复表（约束、索引等）。但是，具有特定于表的转储允许特定于表的恢复。我会查看 WAL 归档建议，谢谢@a_horse_with_no_name！

标签： database postgresql database-backups postgresql-9.6

【解决方案1】：

如果您想要按小时粒度进行备份，您可能应该使用pg_basebackup 和 WAL 归档（或流式传输，从副本归档）来创建物理备份，而不是使用 pg_dump 来创建逻辑备份。然后，您可以使用 PITR 恢复到您想要的几乎任何时间点。您将不得不偶尔进行新的基本备份以缩短恢复时间，但几乎可以肯定不是每小时一次。此外，pg_basebackup 具有较低的 CPU 负载（除了压缩，但如果您通过网络运行 pg_basebackup，这是在本地端而不是数据库端完成的）。

【讨论】：