对于我的担忧，我找不到一个确切的答案，所以我不妨问你们！
**长话短说：**我们需要在大约4亿行上执行UPDATE命令。我知道可以修改该命令以批量工作，但这是另一个主题。我们的问题是WAL变得太大，磁盘空间用完了。我想知道检查点间隔如何与不同的WAL级别一起工作。简单地说，文档中说，较长的检查点间隔“触发”较少的整页写入，这会导致较小的WAL。我找不到的是，在不同的wal_level设置下，这种变化是如何表现的。
**数据库版本：**Postgres14.4
1.它是否与minimal wal_level设置相关？（考虑到它几乎删除了所有日志记录。）
2.当wal_level设置为replica或更高时，是否会中断副本？（根据不同的文章和文档，这一点对我来说并不明显，但我认为副本应该是好的，因为尽管整页/块写入较少，但所有更改都会被记录，而且这也可能是有益的，即减少WAL大小。）
我们正处于一个完全备份和关闭相关应用程序是可能的位置，所以minimal wal_level设置可以工作，但我也对不同的解决方案感兴趣，请随时分享一些想法。
干杯！
2条答案
按热度按时间yhxst69z1#
wal_level = minimal不会有什么影响。只要你不把它设置为logical，PostgreSQL应该产生相同数量的WAL。如果你把wal_level设置为比replica* 低 * 的值，它会破坏复制。显而易见的解决方案是增加更多磁盘空间。如果问题是WAL archiving，则可以禁用
archive_mode。如果问题是检查点需要花费太长时间才能完成，则可以运行手动CHECKPOINT命令。增加
max_wal_size以减少写入的WAL数量。是的，我知道这听起来很奇怪，但是max_wal_size并不控制pg_wal的大小，但是它会触发检查点（这会增加写入的整页图像的数量）。kkbh8khc2#
它是否与最小wal_level设置相关？（考虑到它几乎删除了所有日志记录）
使用minimal，你只跳过了WAL记录的一些事情，比如复制到同一事务中创建或截断的表中，或者创建索引。这些特殊情况不适用于批量UPDATE。
要解决此问题，您首先需要找出根本问题是什么。在正常情况下，您是否非常接近空间不足的情况，以至于任何压力都可以将您推到一边？您是否有复制插槽、而备用设备无法跟上？您是否有无法跟上的archive_command？您的IO系统是否不堪重负，以至于检查点无法'尽管他们尽可能快地尝试，但还是不能及时完成？你的硬盘不能兑现支票吗？