摘要
我们使用Postgresql13中的max_slot_wal_keep_size来防止master被滞后复制杀死。在我们的案例中，WAL存储在超过该参数后似乎没有释放，这导致了复制失败。我认为，WAL本应被释放，但当时任何其他交易似乎都不需要它。我想知道这应该如何工作，为什么WAL段没有被删除
请查看以下详细信息。
配置
- 大师&一个复制副本-使用插槽进行流式复制
- 约700GB可用于pg_wal
max_slot_wal_keep_size = 600GBmin_wal_size = 20GBmax_wal_size = 40GB- 默认
checkpoint_timeout=5分钟(检查点没有问题( - 归档正在进行，并且进展良好
发生了什么
在高负载(大型COPY/INSERT事务，加载数百GB的数据(下，复制开始落后。pg_wal上的可用空间正在以与safe_slotpg_replication_slot.safe_wal_size相同的速率减少——正如预期的那样。在某个时刻，safe_wal_size变为负值，流媒体停止工作。这不是问题，因为复制副本已从WAL归档开始恢复。我预计一旦插槽丢失，WAL将被删除，直到max_wal_size。但这并没有发生。Postgres似乎试图保持接近max_slot_wal_keep_size(600GB(的可用空间，以防复制副本再次赶上。随着时间的推移，没有一笔交易需要保留这么多WAL。归档也没有落后。
-
Q1:PG是否会尝试保持可用WAL的
max_slot_keep_size - Q2:如果没有，为什么PG没有删除过多的WAL，而归档器和系统上运行的任何事务都不需要它们
pg_wal上的可用空间在大部分时间里或多或少都是70GB，但在某个时候，在严重的自动吸尘过程中，它降到了0:(这是pg崩溃的时候，不久后自动恢复(。备份后，pg_wal上还有11GB空间，没有运行任何事务，也没有加载。这持续了几个小时。在此期间，复制副本终于从存档中恢复过来，并毫不延迟地恢复了复制。没有拆除任何WAL。我手动运行检查点，但它没有清除任何WAL。我终于重新启动了Postgresql，在重新启动的过程中，pg_wal终于被清除了。
- Q3:再次-为什么PG没有清除WAL？更清楚的是，任何程序都不需要WAL
非常感谢！
这是一个PostgreSQL错误，已经修复。感谢您的报道！
根据发行说明，它应该在13.4中可用(寻找"Advance oldest required WAL segment"(