如何在频繁的postgres备份场景中最小化带宽?

前端之家收集整理的这篇文章主要介绍了如何在频繁的postgres备份场景中最小化带宽?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我希望在几个虚拟机(比如20-50)上对同一个存档服务器进行非常频繁的postgres数据备份(每小时).

如果需要,以下是更多数据:理想情况下,系统应支持位于所有VM上的80到200个数据库负载.数据库很小(10MB – 100MB)到中等大小(500MB – 2GB),由百分之一的表组成,这些表中的一小部分可以轻松地包含数千行,最多可达到大约一百万行.对数据库的更改通常是新记录,一些更新,而不是删除.带宽为100Mbits / s.

由于我已经使用增量备份(rsync)的标准文件系统这样做,我想知道是否可以使用postgres数据库备份实现类似的功能.

我有几种可能的选择:

>我可以选择将数据库放在可快照的文件系统上(aufs docker风格,ZFS,btrfs,但其中一些似乎真的放慢了postgres).
>如果有必要,我准备好使用WAL
>如果必要的话,我只能在数据库级别进行备份会更好.因为我不需要备份整个postgres数据,只需备份客户数据库.
>我在postgres服务器上有一些可以保留中间备份的磁盘空间.
>我可以在VM端提供一些合理的cpu工作负载,但宁愿在备份服务器上最小化它,因为它会将更多的数据库添加到备份中.
>我不是在寻找持续备份或PITR恢复选项.我的备份服务器有一个基于文件的系统(brfs)来执行备份的高效定期快照.这够好了.

我想过:

>在sql中将rsync与pg_dump本地结合使用到服务器,但我不确定应该使用哪种不同的格式来保持最高效率.
>使用允许在块级别发送二进制差异的快照文件系统(btrfs和ZFS都很擅长),使用或不使用本地转储(关于要使用的备份格式的相同问题).
>我已经了解了pg_rman的存在,我真的不知道它是否可以依赖,并且设置和各种过程似乎比pg_dump稍重.它是否只支持增量备份?我们可以在备份方面有一个实用的格式吗?

除了增量备份还有另一种方法可以达到小带宽吗?

那么……我怎样才能在postgres备份场景中缩小bandwith?

您正在尝试使用笨拙的解决方解决一个经验丰富的问题​​(在真实的数据库系统中);对于大多数来自小型数据库系统背景的人来说,这是可以理解的(我自己用MysqL完成了类似的事情,并且因为带宽井喷的后果而陷入困境).

你应该使用Postgresql的复制功能;见http://www.postgresql.org/docs/9.3/interactive/high-availability.html

原文链接:https://www.f2er.com/postgresql/192265.html

猜你在找的Postgre SQL相关文章