• 使用pg_dump 进行PostgreSQL 逻辑备份的理想做法是什么?
• 从备用/从属节点进行备份是否理想?如果复制延迟小于 200 毫秒
• 从备用/从属节点进行备份是否理想?是否需要更改任何特定配置?
• 哪种备份方法是逻辑备份或物理备份的好方法? DB 经常更新。当备份用于灾难恢复时,哪种方法是更快、更好的备份和灾难恢复(恢复)。
updated
我们当前的数据库大小为 5GB,并且复制已开启hot standby
mode.
我们在从节点上运行备份脚本,但它每 30 分钟从主节点进行一次远程备份。
我创建这个问题的原因是为了了解备份何时运行COPY
语句需要 6 分钟才能完成,即使它不会影响数据库上的其他事务,如果语句花费更多时间,是否会出现任何其他问题。
我考虑了你写的内容,这里有一些想法供你参考:
- 如果您需要真正与某个时间点保持一致的备份,那么您必须使用 pg_basebackup 或 pg_barman (内部使用 pg_basebackup) - 解释在下面的 1. 链接中。最新的 pg_basebackup 10 流式传输 WAL 日志,因此您还可以备份备份期间完成的所有更改。当然,这个备份只需要整个PG实例。另一方面,它不锁定任何表。如果您从远程实例执行此操作,那么它只会在 PG 实例上造成较小的 CPU 负载,并且磁盘 IO 不会像某些文本建议的那么大。有关我的经历,请参阅链接 4。恢复非常简单 - 请参阅链接 5。
- 如果您使用 pg_dump,您必须明白,您无法保证您的备份与时间点确实一致 - 再次参见链接 1。可以使用数据库快照(参见链接 2 和 3),但即使使用它你不能指望 100% 的一致性。我们仅在分析数据库上使用 pg_dump,该数据库每天仅加载 1 次新数据(昨天来自生产数据库的分区)。您可以使用并行选项加速它(仅适用于目录备份格式)。但缺点是 PG 实例的负载要高得多 - CPU 使用率更高,磁盘 IO 更高。即使您远程运行 pg_dump - 在这种情况下,您也只节省磁盘 IO 来保存备份文件。另外 pg_dump 需要在表上放置读锁,这样它就可以与新插入或复制(当在副本上进行时)发生冲突。但是,当您的数据库达到数百 GB 时,即使并行转储也可能需要几个小时,此时您无论如何都需要切换到 pg_basebackup。
- pg_barman 是 pg_basebackup 的“舒适版本”+它可以让你防止数据丢失,即使你的 PG 实例崩溃得很严重。让它发挥作用需要更多的改变,但这绝对是值得的。你必须设置WAL日志归档(参见链接6),如果你的PG
您的数据库有 5GB 大,因此任何备份方法都会很快。但您必须决定是否需要时间点恢复和几乎零数据丢失 - 因此您是否愿意花时间设置 pg-barman。
Links:
- PostgreSQL、备份以及您需要了解的一切 https://www.compose.com/articles/postgresql-backups-and-everything-you-need-to-know/
-
论文评论:PostgreSQL 中的 14-可序列化快照隔离 https://web.eecs.umich.edu/~mozafari/fall2015/eecs584/reviews/summaries/summary14.html- 关于快照
-
数据库并行转储 https://www.depesz.com/2013/03/05/parallel-dumping-of-databases/- 示例如何使用快照
- pg_basebackup 经验 http://postgresql.freeideas.cz/pg_basebackup-experiences/
- pg_basebackup - 恢复 tar 备份 http://postgresql.freeideas.cz/pg_basebackup-pgbarman-restore-tar-backup/
- 使用脚本归档 WAL 日志 http://postgresql.freeideas.cz/streaming-replication-pg-barman-archiving-wal-logs-using-script/
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)