复制滞后 - 超过 max_slot_wal_keep_size，未删除 WAL 段
Replication lag - exceeding max_slot_wal_keep_size, WAL segments not removed
总结
我们正在使用 max_slot_wal_keep_size from Postgresql 13 来防止 master 被滞后的复制杀死。看起来，在我们的例子中，WAL 存储在超过导致复制失败的这个参数后没有被释放。 WAL，正如我所相信的那样，应该被释放，但似乎同时没有被任何其他交易所需要。我想知道这应该如何工作以及为什么没有删除 WAL 段？
详情请见下方。
配置
- master & one replica - streaming replication using a slot
- ~700GB 可用于 pg_wal
max_slot_wal_keep_size = 600GBmin_wal_size = 20GBmax_wal_size = 40GB- 默认
checkpoint_timeout = 5分钟（检查点没问题）
- 存档工作正在进行中，进展顺利
发生了什么事
在重负载下（大型 COPY/INSERT 事务，加载数百 GB 的数据），复制开始落后。 pg_wal 上可用的 space 正在以与 safe_slot pg_replication_slot.safe_wal_size 相同的速度减少 - 正如预期的那样。在某个时候 safe_wal_size 变为负值，流式传输停止工作。这不是问题，因为副本开始从 WAL 存档恢复。我预计一旦插槽丢失，WAL 将被删除最多 max_wal_size。但这并没有发生。似乎 Postgres 试图保持接近 max_slot_wal_keep_size (600GB) 可用的东西，以防副本再次开始追赶。随着时间的推移，没有一个事务需要保留这么多 WAL。归档也不落后。
- Q1: PG 是否会尝试维持
max_slot_keep_size 个 WAL 可用？
- 问题 2： 如果不是，为什么 PG 没有删除过多的 WAL，而归档程序和系统上的任何事务都不需要它们 运行ning？
pg_wal 上的可用空间 space 大部分时间大约为 70GB，但是在某些时候，在大量自动清理期间，它会下降到 0 :( 这就是 PG 崩溃的时候并且（不久之后自动恢复）。备份后，pg_wal 上还剩 11GB，没有事务 运行ning，没有加载。这持续了几个小时。在此期间，副本终于从存档并立即恢复复制。None 的 WAL 被删除。我手动 运行 检查点但它没有清除任何 WAL。我最终重新启动了 Postgresql 并在重新启动期间 pg_wal终于清零了
- Q3: 再一次——为什么PG没有清除WAL？更清楚的是，任何进程都不需要 WAL。
非常感谢！
这是一个 PostgreSQL 错误，现在 fixed。感谢举报！
总结
我们正在使用 max_slot_wal_keep_size from Postgresql 13 来防止 master 被滞后的复制杀死。看起来，在我们的例子中，WAL 存储在超过导致复制失败的这个参数后没有被释放。 WAL，正如我所相信的那样，应该被释放，但似乎同时没有被任何其他交易所需要。我想知道这应该如何工作以及为什么没有删除 WAL 段？
详情请见下方。
配置
- master & one replica - streaming replication using a slot
- ~700GB 可用于 pg_wal
max_slot_wal_keep_size = 600GBmin_wal_size = 20GBmax_wal_size = 40GB- 默认
checkpoint_timeout= 5分钟（检查点没问题） - 存档工作正在进行中，进展顺利
发生了什么事
在重负载下（大型 COPY/INSERT 事务，加载数百 GB 的数据），复制开始落后。 pg_wal 上可用的 space 正在以与 safe_slot pg_replication_slot.safe_wal_size 相同的速度减少 - 正如预期的那样。在某个时候 safe_wal_size 变为负值，流式传输停止工作。这不是问题，因为副本开始从 WAL 存档恢复。我预计一旦插槽丢失，WAL 将被删除最多 max_wal_size。但这并没有发生。似乎 Postgres 试图保持接近 max_slot_wal_keep_size (600GB) 可用的东西，以防副本再次开始追赶。随着时间的推移，没有一个事务需要保留这么多 WAL。归档也不落后。
- Q1: PG 是否会尝试维持
max_slot_keep_size个 WAL 可用？ - 问题 2： 如果不是，为什么 PG 没有删除过多的 WAL，而归档程序和系统上的任何事务都不需要它们 运行ning？
pg_wal 上的可用空间 space 大部分时间大约为 70GB，但是在某些时候，在大量自动清理期间，它会下降到 0 :( 这就是 PG 崩溃的时候并且（不久之后自动恢复）。备份后，pg_wal 上还剩 11GB，没有事务 运行ning，没有加载。这持续了几个小时。在此期间，副本终于从存档并立即恢复复制。None 的 WAL 被删除。我手动 运行 检查点但它没有清除任何 WAL。我最终重新启动了 Postgresql 并在重新启动期间 pg_wal终于清零了
- Q3: 再一次——为什么PG没有清除WAL？更清楚的是，任何进程都不需要 WAL。
非常感谢！
这是一个 PostgreSQL 错误，现在 fixed。感谢举报！