PostgreSQL - 不同 WAL 级别的检查点间隔行为

Question

我的顾虑找不到确切的答案，不妨问问你们！

长话短说： 我们需要对大约 400M 行执行更新命令。我知道可以修改该命令以分批工作，但这是另一个话题。我们的问题是 WAL 变得太大，我们用完了磁盘空间。 我想知道检查点间隔如何与不同的 WAL 级别一起工作。简而言之，文档说较长的检查点间隔“触发”较少的整页写入，从而导致较小的 WAL。我找不到的是这种变化如何在不同的 wal_level 设置下表现。

数据库版本： Postgres14.4

1。它与

minimal

wal_level 设置有任何关联吗？（考虑到它几乎删除了所有日志记录。）

2。当 wal_level 设置为

replica

或更高时，它会破坏副本吗？ （根据不同的文章和文档，这对我来说并不明显，但我认为副本应该没问题，因为尽管记录了所有更改更少的整页/块写入，它也可能是有益的，即减少 WAL 大小。）

我们处于可以完全备份和关闭相关应用程序的位置，因此

minimal

wal_level 设置可以工作，但我也对不同的解决方案感兴趣，请随时分享一些想法。

干杯！

Answer 1

wal_level = minimal

不会有什么不同。只要您不将其设置为

logical

，PostgreSQL 就应该产生大约相同数量的WAL。如果您将

wal_level

设置为 lower 低于

replica

，它将破坏复制。

显而易见的解决方案是增加更多的磁盘空间。如果问题是 WAL archiving，您可以禁用

archive_mode

。如果问题是检查点需要太长时间才能完成，您可以运行手动

CHECKPOINT

命令。

增加

max_wal_size

以减少写入的WAL量。是的，我知道这听起来很奇怪，但是

max_wal_size

确实 not 控制

pg_wal

的大小，但它会触发检查点（这会增加写入的整页图像的数量）。

Answer 2

它与最小 wal_level 设置有任何关联吗？ （考虑到它几乎删除了所有日志记录。）

没有。使用 minimal，您只跳过一些事情的 WAL 日志记录，例如 COPY 到在同一事务中创建或截断的表中，或者创建索引。这些特殊情况不适用于批量更新。

要解决问题，首先要弄清楚根本问题是什么。在正常情况下，您是否已经接近空间不足状态，以至于任何压力都无法将您推倒？您是否有复制槽，而备用数据库跟不上？您是否有无法跟上的 archive_command？您的 IO 系统是否不堪重负，以致于尽管尽可能快地尝试，检查点仍无法及时完成？你是 max_wal_size 写支票你的硬盘不能兑现吗？

Answer 3

确定一些要点：

• checkpoint_time

  和

  max_wal_size

  都不算小
• 你的

  archive_command

  正在工作。

这些点对于避免 I/O 系统泛滥很重要。