我们不能轻易地再次阻止主人.
我们能做到吗
> pg_start_backup(),
> rsync ${PGDATA} / master to slave,
> pg_stop_backup()
…虽然主postgresql仍然满负荷？
(或者pg_start_backup()会导致
>表锁,
> I / O块,
>不一致,
>火警,
>缓慢的数据库响应
换句话说,pg_start_backup()会影响我们的应用程序吗？
您需要担心的是rsync或等效的pg_basebackup步骤.从这里读取I / O并不会太糟糕,因为它是连续的,但它仍然可能会严重损害数据库的I / O性能,并且它也会倾向于将热数据推出RAM缓存,而不是 – 使用的数据,导致缓存抖动,然后读回更多需要的数据.
您可以使用nice和ionice来帮助限制I / O影响(但不影响缓存影响);然而,这是一个成本.备份将花费更长时间,直到你完成备份并运行pg_stop_backup你的系统 – 据我所知 – 累积WAL它无法删除,在备份运行结束时为BIG检查点累积检查点债务,并且正在累积表和索引膨胀,因为它无法清理死行.因此,您真的无法承担永久备份,特别是如果您有非常高的流失表.
最后,很难说您是否可以安全地在您的环境中使用pg_start_backup和pg_stop_backup进行热备份.大多数人都可以,但如果你接近硬件可以做的边缘,有严格的时间要求,不能承受失速的风险,并且有非常高的流失表以及非常大的表,它可能会很麻烦.
不幸的是,你几乎需要测试它并看到.
如果可以的话,可能值得发出一个CHECKPOINT,然后使用LVM,SAN工具,EBS或其他任何东西来获取数据库所在卷的原子快照.如果您可以这样做,则可以随意复制快照.这种方法不适合为PITR /热备份/热备用进行基本备份,但它对于静态备份副本非常有用,并且对系统的影响要小得多.如果快照是原子的,并且整个数据库(包括WAL)位于单个卷上,则只能执行此操作.
我尚未研究的一种可能性是将这两种方法结合起来.在我看来,一个人可能(未经测试,可能错误和不安全,我还不知道)：
> pg_start_backup
>触发所有表空间,主数据库和xlog卷的快照
> pg_stop_backup
>将WAL从pg_stop_backup复制到最终存档
>从快照卷复制数据
从本质上讲,这个想法是通过记录您可以随意复制的每个卷的时间点来减少数据库延迟检查点的时间.
