我已将 cron 配置为每天使用以下规则调用 pg_dump：
# xyz database backups:
00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz
基本上，它起作用了。数据库增长相对较快，呈指数级增长（但指数不是很大）。目前，经过 gzip 压缩的转储大约需要 160MB。转储数据库时，系统开始缓慢运行。使用该top命令时我看到的平均负载约为200, 200, 180。基本上，服务器几乎没有响应。
这第一个问题是如何确定瓶颈在哪里。性能不佳是由繁重的 I/O 操作引起的吗？是由表锁定问题引起的吗？也许是内存问题？命令的输出通过pg_dump管道传输到gzip命令。它是顺序的，即整个转储都放在内存中（交换问题？）然后压缩还是并发（即 gzip 压缩它得到的内容并等待更多）？可能是由其他因素引起的吗？
这第二个问题是如何使转储操作对系统主要功能的干扰更小。据我所知，由于数据库完整性，转储不能花费太多时间。有表写锁等。我可以做些什么来限制问题（或延迟它，考虑到数据库的增长）。
这第三个问题：现在是时候了解更高级的数据库配置了吗？当不执行数据库备份时，系统运行正常，但数据库转储问题可能是即将出现问题的第一个症状？
答案1
哇。问题数量惊人。我会尝试回答一些，但这个答案还不完整。
如何确定瓶颈在哪里。
首先使用top来查看转储期间发生了什么。检查进程 CPU 使用率、进程状态。D表示“等待 I/O”。
性能不佳是否由繁重的 I/O 操作导致？
是的，很有可能。
这是由表锁定问题引起的吗？
也许。您可以使用pg_stat_activity系统视图来查看转储期间 postgres 中发生的情况。
也许是记忆问题？
不太可能。
pg_dump 命令的输出通过管道传输到 gzip 命令。它是连续的吗，即整个转储都放在内存中（交换问题？）
不。gzip 是一个以流模式工作的块压缩器，它不会将所有输入都保存在内存中。
然后压缩或并发（即 gzip 压缩它所得到的内容并等待更多内容）？
是的，它逐块压缩，输出并等待更多。
这可能是由其他因素造成的吗？
是的。
据我所知，由于数据库完整性，转储不能花费太多时间。有表写锁等。我可以做些什么来限制问题（或延迟它，考虑到数据库的增长）。
转储持续时间对转储完整性没有影响。使用一个事务来确保完整性可重复读所有 pg_dump 进程的隔离级别。常规 INSERT/UPDATE 没有表写入锁定。备份期间只能阻止某些 DDL 操作（DROP TABLE、ALTER TABLE 等）。
是时候了解更高级的数据库配置了吗？当不执行数据库备份时，系统运行正常，但数据库转储问题可能是即将出现问题的第一个症状？
永远不会太晚。从开始http://wiki.postgresql.org/wiki/Performance_Optimization。
答案2
我建议你看看连续存档postgresql。与使用 pg_dump 相比，优点如下：
- 不需要每次都进行完整备份。开始时一次完整备份就足够了，但建议每隔几天进行一次完整备份。
- 当数据库规模增大时，恢复速度会快得多。
- 恢复到其他点的能力（时间点恢复）。
- 您将每小时（约 30 分钟）进行一次增量备份。这可以配置，并且还取决于更新活动。
但是，也存在一些缺点（在大多数情况下可能不是问题）：
- 通常需要更多空间，因为这些是二进制备份。DB 文件夹可以压缩。
- 您无法在不同的架构（二进制数据）上恢复它们。