Postgresql 数据库备份 理想实践

Question

• 使用 pg_dump 进行 PostgreSQL 逻辑备份的理想做法是什么？

• 从备用/从节点进行备份是否理想？如果复制延迟小于 200ms

• 从备用/从节点备份是否理想，是否需要更改任何特定配置？

• 哪种方法是进行逻辑备份或物理备份的好方法？ DB经常更新的地方。作为备份进行灾难恢复，哪种方法是更快更好的备份和灾难恢复（恢复）。

updated
我们当前的数据库大小为 5GB，复制处于hot standby 模式。
我们在从节点上运行备份脚本，但它每 30 分钟从主节点进行远程备份。
我创建这个问题的原因是要了解备份何时运行一些 COPY 语句需要 6 分钟才能完成，即使它不会影响数据库上的其他事务，如果语句花费更多时间，是否还会出现任何其他问题。

Answer 1

我想到了你写的东西，这里有一些想法给你：

1. 如果您需要在某个时间点真正保持一致的备份，那么您必须使用 pg_basebackup 或 pg_barman（内部使用 pg_basebackup） - 解释在下面的 1. 链接中。最新的 pg_basebackup 10 个流 WAL 日志，因此您还可以备份备份期间完成的所有更改。当然，这个备份只需要整个 PG 实例。另一方面，它不锁定任何表。如果您从远程实例执行此操作，那么它只会导致 PG 实例上的 CPU 负载很小，并且磁盘 IO 并不像某些文本所暗示的那么大。有关我的经验，请参阅链接 4。恢复非常简单 - 请参阅链接 5。
2. 如果您使用 pg_dump，您必须了解您不能保证您的备份与时间点真正一致 - 再次参见链接 1。可以使用数据库快照（参见链接 2 和 3）但是即使有了它，您也不能指望 100% 的一致性。我们只在我们的分析数据库上使用了 pg_dump，它每天只加载 1 次新的（昨天从生产数据库中的分区）。您可以使用并行选项加速它（仅适用于目录备份格式）。但缺点是 PG 实例的负载要高得多 - CPU 使用率更高，磁盘 IO 更高。即使您远程运行 pg_dump - 在这种情况下，您只保存磁盘 IO 来保存备份文件。另外 pg_dump 需要在表上放置读锁，以便它可以与新插入或复制（当在副本上进行时）发生冲突。但是，当您的数据库达到数百 GB 时，即使是并行转储也可能需要数小时，此时您无论如何都需要切换到 pg_basebackup。
3. pg_barman 是 pg_basebackup 的“舒适版”+ 它可以让您防止数据丢失，即使您的 PG 实例崩溃非常严重。让它工作需要更多的改变，但这绝对是值得的。您必须设置 WAL 日志归档（参见链接 6），如果您的 PG

您的数据库有 5GB 大，因此任何备份方法都会很快。但是您必须决定是否需要时间点恢复和几乎零数据丢失 - 所以您是否会花时间设置 pg-barman。

链接：

1. PostgreSQL, Backups and everything you need to know
2. Review for Paper: 14-Serializable Snapshot Isolation in PostgreSQL - 关于快照
3. Parallel dumping of databases - 示例如何使用快照
4. pg_basebackup experiencies
5. pg_basebackup - restore tar backup
6. Archiving WAL logs using script