Postgresql 在达到 max_wal_size 以上后无法归档 WAL

Question

我已经使用

crunchydata

k8s 运算符部署了 PostgreSQL(v13)。

目前我发现

max_wal_size

是

1GB

使用：

DB=# show max_wal_size;
 max_wal_size 
--------------
 1GB
(1 row)

但是当前的

/pgdata/pg13_wal

尺寸是

4.9Gi

。为什么 PostgreSQL 无法归档

wal

并减小

wal

大小。

日志

Backup start location: 0/0
Backup end location: 0/0
End-of-backup record required: no
wal_level setting: logical
wal_log_hints setting: on
max_connections setting: 100
max_worker_processes setting: 8
max_wal_senders setting: 10
max_prepared_xacts setting: 0
max_locks_per_xact setting: 64
track_commit_timestamp setting: off
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float8 argument passing: by value
Data page checksum version: 1

Answer 1

max_wal_size 是让 WAL 在自动检查点期间增长的最大大小。这是一个软限制；在特殊情况下，例如重负载、archive_command 失败或 wal_keep_size 设置较高，WAL 大小可能会超过 max_wal_size。如果指定该值时没有单位，则以兆字节为单位。默认值为 1 GB。增加此参数可以增加崩溃恢复所需的时间。该参数只能在 postgresql.conf 文件或服务器命令行中设置。

Answer 2

Postgres 中的 max_wal_size 参数被描述为软限制，以帮助防止 WAL 变得太大。默认值为 1024 MB（参数以 MB 为单位设置。）这并不是很多。

当达到这个值时，它基本上会向 Postgres 发出信号，要求其执行检查点并将缓冲区中的所有数据刷新到磁盘。一旦检查点完成，那些本来可以在缓冲区中的数据的 WAL 段就可以被删除。完成检查点可能需要一些时间，因为 Postgres 确实需要等待事务完成。因此是软限制。

检查站并不便宜。管理员倾向于将时间段保持相对较长，以最大限度地提高吞吐量。但另一方面，如果数据库发生故障，您的恢复时间取决于 WAL 的大小，您必须重播该 WAL 才能恢复数据库。这意味着您想要增加检查点频率。

此描述中没有任何内容与逻辑复制相关。在这些情况下，您会发现管理员建议您持有足够的 WAL 来弥补最大延迟。

为此，您需要设置 wal_keep_size，而不是 max_wal_size。这是要保留的最小 WAL 大小。例如，如果您认为只读副本或备用服务器最多可以有 2 小时的停机时间，您可以将 wal_keep_size 设置为至少最大 wal 大小/小时 * 2 小时。

keep_wal_size 的默认值为 0。这并不是很多。

此外，这一切仍然没有涉及数据管道的变更数据捕获（CDC）。有吗

是的，有。 wal_keep_size 是你的规则，无论你喜欢与否。

您需要让管理员设置 keep_wal_size。然后，您需要在达到保留大小之前的几个小时内提取 WAL。否则，您可能需要重新启动 CDC 并拍摄新快照，因为一旦发生检查点，您可能无法再获取最旧的 WAL 段。

简而言之，

1. 始终与您的 Postgres 管理员密切合作，协调 Postgres keep_wal_size 和 max_wal_size。您最不想做的就是频繁重新启动 CDC 管道。
2. 构建您的 CDC 以立即读取 WAL。不要进行间隔较长的批量读取。

您的 CDC 需要像数据库一样思考并立即读取 WAL，这就是预期的设计。

快照完成后，您将看到 Debezium 进行读取。使用 DDD-3 减少锁定。 Estuary 立即执行 WAL 读取并并行启动增量快照，没有任何延迟，并将快照与 WAL 读取合并。这是最好的方法。