Postgres13+Patroni集群pg_wal持续膨胀问题排查求助

AI 小北

2026-8-6

pg_wal目录膨胀原因分析

结合你提供的集群配置与查询数据，导致pg_wal持续膨胀的核心原因如下：

wal_keep_segments设置过大
你的Patroni配置中指定wal_keep_segments: 5120，每个Postgres WAL段默认大小为16MB，这意味着集群会强制保留至少5120 * 16MB = 80GB的WAL文件。该参数优先级高于max_wal_size，即使主库完成检查点，只要WAL段数量未低于5120，Postgres就不会删除旧WAL。当前pg_wal目录有5127个文件，总规模与该参数计算值高度匹配，这是导致膨胀的主要因素。
max_wal_size限制被覆盖
虽然配置了max_wal_size: 1G，但该参数仅控制检查点周期内生成的WAL总量。当存在活跃复制槽或配置了wal_keep_segments时，Postgres会优先满足复制需求，不会删除从库或复制槽依赖的WAL，因此max_wal_size的限制完全失效。
复制槽的WAL保留机制
两个活跃物理复制槽（db1、db2）会强制保留restart_lsn之后的所有WAL，直到从库确认接收并处理这些数据。虽然Patroni显示从库延迟为0，但复制槽的confirmed_flush_lsn为空，说明从库未向主库上报WAL刷盘的确认信息——不过结合当前WAL数量与wal_keep_segments的匹配度，这并非当前膨胀的直接原因，但如果后续复制槽restart_lsn停滞，可能会加剧膨胀问题。
未启用WAL归档
archive_mode: off导致WAL无法归档到外部存储，仅当WAL不再被复制槽或wal_keep_segments需要时才会被删除。归档关闭本身不是当前膨胀的直接原因，但启用归档后，可通过archive_cleanup_command自动清理已归档的WAL，同时避免复制槽或从库异常时WAL被过早删除。