PostgreSQL：我可以在加载的实时运行数据库上执行pg_start_backu

dezso指出,pg_start_backup将执行一个检查点.这确实有影响,但是你的数据库无论如何都会定期执行检查点,并且必须这样才能运行,所以它们对你来说显然不是问题.早期检查点意味着累积的数据较少,这意味着如果有任何事情,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复制到最终存档
>从快照卷复制数据

从本质上讲,这个想法是通过记录您可以随意复制的每个卷的时间点来减少数据库延迟检查点的时间.