Postgresql DB 备份的理想做法 [英] Postgresql DB backup Ideal practices

问题描述

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

• What are ideal practices for taking PostgreSQL logical backup using pg_dump?

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

• Is it ideal to take backup from a standby/slave node? If replication lag is less than 200ms

• 从备用/从节点进行备份是否理想，我们是否需要更改任何特定配置?

• Is it ideal to take backup from standby/slave node, and is there any specific configuration we need to change?

• 哪种方法是进行逻辑备份或物理备份的好方法?数据库经常更新的地方.作为灾难​​恢复的备份，哪种方法是更快更好的备份和灾难恢复(恢复).

• Which method is a good way for taking backups logical backup or physical backup? where DB is getting updated frequently. As a backup is taken for disaster recovery which method is the faster and better backup and disaster recovery(restore).

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

updated
Our current database size is 5GB and replication is on hot standby mode.
We are running the Backup script on slave node but it takes remote backup from the master node every 30 minutes.
The reason I created this question is to understand when the backup is running some COPY statements takes 6 mins to complete, even though it will not affect other transactions on DB, is there any other issues occurs if a statement is taking more time.

推荐答案

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

I thought about what you wrote and here are some ideas for you:

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 <10，则必须设置max_wal_senders"和max_replication_slots"(无论如何您都需要复制)-尽管一切都在 pg-barman 手册中描述不是很好.pg_barman 甚至会在备份之间流式传输和存储 WAL 记录，这样您就可以确保在非常严重的崩溃情况下几乎没有数据丢失.但是使其工作可能需要很多小时，因为描述并不完全正确.pg-barman 使用其命令进行备份和恢复.

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

Your database is 5GB big so any backup method will be quick. But you have to decide if you need point in time recovery and almost zero data loss or not - so if you will invest time to setting pg-barman or not.

链接:

1. PostgreSQL、备份和您的一切需要知道
2. 论文审查:14-可序列化快照PostgreSQL 中的隔离 - 关于快照
3. 并行转储数据库 - 示例如何使用快照
4. pg_basebackup 体验
5. pg_basebackup - 恢复 tar 备份
6. 使用脚本归档 WAL 日志

1. PostgreSQL, Backups and everything you need to know
2. Review for Paper: 14-Serializable Snapshot Isolation in PostgreSQL - about snapshots
3. Parallel dumping of databases - example how to use snapshot
4. pg_basebackup experiencies
5. pg_basebackup - restore tar backup
6. Archiving WAL logs using script

这篇关于Postgresql DB 备份的理想做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！