如何减少 postgresql 中生成的 WAL 文件的数量答案

【问题标题】：how to reduce amount of WAL files generated in postgresql如何减少 postgresql 中生成的 WAL 文件的数量
【发布时间】：2022-06-15 17:24:27
【问题描述】：

在Master-Standby复制中会产生大量的WAL文件。 walfiles 在备用节点之一存档，每 2 小时，我们使用tar 压缩备用节点中的存档 WAL。尽管如此，它仍然是一个巨大的存储空间。当涉及到 30、90 天的备份时，它会成为一个巨大的存储问题。此外，在恢复期间最终需要更多时间来下载和重播 WAL。

我使用了以下选项。

wal_level=replica
wal_compression=on
archive_mode = always

以下参数已注释/未使用。

archive_timeout
checkpoint_timeout

有没有其他方法，我们可以减少生成的 WAL 的数量或更简单的方法来管理它们？ pg_waldump 显示大约 70-90% 的数据是整页图片。

另外，我可以通过更改备用节点使上述参数生效吗？备用存档是否与主服务器发送的相同 WAL？还是根据备用配置重新生成？

-- 更新：修改为以下值

        name        | setting | unit
--------------------+---------+------
 archive_timeout    | 0       | s
 checkpoint_timeout | 3600    | s
 checkpoint_warning | 3600    | s
 max_wal_size       | 4000    | MB
 min_wal_size       | 2000    | MB
 shared_buffers     | 458752  | 8kB
 wal_buffers        | 4096    | 8kB
 wal_compression    | on      |
 wal_level          | replica |

仍然看到每分钟生成 3-4 个 WAL 文件。我正在热备用节点上进行这些更改（从那里进行备份）。我应该在Master中改变这个吗？ master 设置对 Standby 的 WAL 生成有影响吗？

显示 FPI 大小=87% 的示例 pg_waldump

pg_waldump --stats 0000000100000498000000B2
Type                                           N      (%)          Record size      (%)             FPI size      (%)        Combined size      (%)
----                                           -      ---          -----------      ---             --------      ---        -------------      ---
XLOG                                           1 (  0.00)                  114 (  0.01)                    0 (  0.00)                  114 (  0.00)
Transaction                                 3070 ( 10.35)               104380 (  4.86)                    0 (  0.00)               104380 (  0.63)
Storage                                        0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
CLOG                                           0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
Database                                       0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
Tablespace                                     0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
MultiXact                                      0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
RelMap                                         0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
Standby                                        2 (  0.01)                  100 (  0.00)                    0 (  0.00)                  100 (  0.00)
Heap2                                        590 (  1.99)                33863 (  1.58)                46192 (  0.32)                80055 (  0.48)
Heap                                        6679 ( 22.51)               578232 ( 26.92)              4482508 ( 30.92)              5060740 ( 30.41)
Btree                                      19330 ( 65.14)              1430918 ( 66.62)              9967524 ( 68.76)             11398442 ( 68.48)
Hash                                           0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
Gin                                            0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
Gist                                           0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
Sequence                                       0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
SPGist                                         0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
BRIN                                           0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
CommitTs                                       4 (  0.01)                  120 (  0.01)                    0 (  0.00)                  120 (  0.00)
ReplicationOrigin                              0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
Generic                                        0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
LogicalMessage                                 0 (  0.00)                    0 (  0.00)                    0 (  0.00)                    0 (  0.00)
                                        --------                      --------                      --------                      --------
Total                                      29676                       2147727 [12.90%]             14496224 [87.10%]             16643951 [100%]

使用log_checkpoints=on后

2022-06-15 07:08:57 UTC [11] LOG:  checkpoint starting: time
2022-06-15 07:29:57 UTC [11] LOG:  checkpoint complete: wrote 67010 buffers (14.6%); 0 WAL file(s) added, 12 removed, 56 recycled; write=1259.767 s, sync=0.010 s, total=1259.961 s; sync files=253, longest=0.003 s, average=0.001 s; distance=1125728 kB, estimate=2176006 kB
2022-06-15 07:38:57 UTC [11] LOG:  checkpoint starting: time
2022-06-15 07:59:57 UTC [11] LOG:  checkpoint complete: wrote 61886 buffers (13.5%); 0 WAL file(s) added, 20 removed, 10 recycled; write=1259.740 s, sync=0.005 s, total=1259.878 s; sync files=185, longest=0.002 s, average=0.001 s; distance=491822 kB, estimate=2007588 kB

【问题讨论】：

许多数据更改导致许多 WAL，这就是生命。您可以增加max_wal_size 和checkpoint_timeout 以减少WAL 中的检查点和整页图像的数量，这将在一定程度上减少WAL 的数量，但代价是更长的崩溃恢复。
@LaurenzAlbe checkpoint_timeout 未设置。根据 WAL 的数量，我认为没有一个 WAL 是空的。因为到达了检查点，所以它们都没有生成。顺便说一句，我到达这里 cybertec-postgresql.com/en/… 并启用了 wal_compression=on。我已经在使用 tar 来压缩它们。需要看到区别。谢谢！
检查点不会导致 WAL 切换。我建议的目的是在 WAL 中获得更少的完整 8kB 页面图像。页面在检查点后第一次被弄脏时，将整个页面写入 WAL。
@LaurenzAlbe 知道了。是否有任何经验法则或任何规则来为 checkpoint_timeout 设置一个合适的值？ pg_waldump 显示在 70-90 周围的数据百分比是 FPI。

标签： postgresql replication database-replication database-backups wal

【解决方案1】：

wal_compression=on

这可能会适得其反。这种类型的压缩需要单独压缩每个 WAL 记录，而不需要更大的上下文。所以这不是很有效。但是，当您在离线状态下重新压缩整个 WAL 文件时，它们确实可以访问更大的上下文，第一轮压缩尝试会干扰更好的压缩尝试。

例如，如果我从 1,000,000 个 pgbench 事务中获取 WAL，它们在没有 wal_compression 的情况下占用 889192448 个原始字节，而在有 wal_compression 的情况下占用 637534208 个。

但是在将它们通过“xz”（一个非常缓慢但非常彻底的压缩器）之后，第一组需要 129393020 字节，而第二组需要 155769400。所以过早打开压缩会花费我 20% 以上的空间。

您可以在某些 WAL 文件上使用 pg_waldump --stat ... 来查看其中的实际内容。如果主要是 FPI，那么您可以尝试使检查点相距更远以降低 FPI 频率。但是，如果您没有太多的 FPI 开始，那将是无效的。如果你能隔离造成如此多 WAL 的原因，也许你可以做点什么。例如，如果您执行大量退化更新，其中列设置为与已有的值相同的值，添加 WHERE 来抑制这些情况可以节省大量 WAL 生成。

【讨论】：

感谢您指向 pg_waldump。不错的工具。根据pg_waldump，每个 WAL 上的 FPI 大小约为 70%-90%。这是否意味着检查点应该相距更远？在 DB 上生成足够的数据之前不必要地生成了 WAL？

【解决方案2】：

正在生成的 WAL 反映了您的主要机器活动。增加 checkpoint_timeout 将有助于减少您的整体机器活动，从而更容易处理 WAL 日志。

备用存档是处理主服务器发送的日志。它们是二进制相同的。是冷备用还是在发送日志时在备用上处理日志？

【讨论】：

是热备。一旦主数据库中出现任何更改，它也可以在备用数据库中使用。所以我得到的归档日志是由备用服务器新创建的，还是由主服务器提供的？
它们与主服务器相同。
好的。谢谢

【解决方案3】：

由于大部分 WAL 由整页图像组成，因此您可以通过减少检查点的频率来显着减少 WAL 的数量。每当页面在检查点后第一次变脏时，就会将整页图像写入 WAL。您必须付出的代价是更长的崩溃恢复时间。

要降低检查点的频率，请更改以下参数：

checkpoint_timeout（默认 5 分钟）：将其设置为 1 小时左右
max_wal_size（默认 1GB）：将其设置为高于一小时内写入的 WAL 量以匹配checkpoint_timeout 设置

这些设置必须在生成 WAL 的主服务器上进行，而不是在备用服务器上进行。最佳做法是在两台服务器上使用相同的设置。

【讨论】：

我配置了checkpoint_timeout=3600 和max_wal_size=4G。重新启动 docker 运行 psql。我仍然看到每分钟都会生成多个 WAL 文件。一分钟内创建 3-4 个 16MB 的文件。这不是不正常吗？另外，我使用了下面的命令pg_waldump --stats 0000000100000385000000EF 并得到 FPI 为 70-90% 我应该指定 LSN 吗？
对不起，我的错。 .conf 的参数设置为4GB。但终端显示 ``` name | max_wal_size 设置 | 4096 单元 | MB```
我在更改后更新了问题的更多详细信息。每分钟仍然有 3-4 个 WAL 文件。
您必须在主节点上更改它。尝试使用max_wal_size = 10GB 以确保安全。使用log_checkpoints = on 查看您获得检查点的频率。整页图片的数量应随着时间的推移而减少。
我已将值增加到max_wal_size = 8GB 和checkpoint_timeout=1800。我仍然在一分钟内看到多个 walfile。示例 WALfile 显示 FPI 约为 80-%，我使用了以下命令：`pg_waldump --stats 00000001000003BE000000CB`并得到`FPI size=14070852 [84.65%]`。