pg_wal 文件夹里面的wal文件一直没删除 一直曾 不知道这东西怎么清理

在某些情况下，WAL 文件消耗的 PostgreSQL 磁盘空间可能会激增或超出正常比例。这种情况有几个可能的原因：

连接器接收到数据的 LSN在服务器视图的confirmed_flush_lsn列中可用。pg_replication_slots早于此 LSN 的数据不再可用，数据库负责回收磁盘空间。

同样在pg_replication_slots视图中，该restart_lsn列包含连接器可能需要的最旧 WAL 的 LSN。如果 for 的值confirmed_flush_lsn定期增加并且值 restart_lsn滞后，则数据库需要回收空间。

数据库通常以批处理块的形式回收磁盘空间。这是预期行为，无需用户采取任何行动。

正在跟踪的数据库中有许多更新，但只有极少数更新与连接器正在捕获更改的表和模式相关。这种情况可以通过周期性的心跳事件轻松解决。设置heartbeat.interval.ms连接器配置属性。

PostgreSQL 实例包含多个数据库，其中一个是高流量数据库。Debezium 捕获与另一个数据库相比流量较低的另一个数据库中的更改。然后，Debezium 无法确认 LSN，因为复制槽在每个数据库中工作，并且没有调用 Debezium。由于 WAL 由所有数据库共享，因此使用量趋于增长，直到 Debezium 正在捕获更改的数据库发出事件。为了克服这个问题，有必要：

heartbeat.interval.ms使用连接器配置属性启用定期心跳记录生成。

定期从 Debezium 捕获更改的数据库中发出更改事件。

在wal2json解码器插件的情况下，生成空事件就足够了。这可以通过例如截断一个空的临时表来实现。对于其他解码器插件，建议创建一个 Debezium 未捕获更改的补充表。

然后，一个单独的进程将通过插入新行或重复更新同一行来定期更新表。PostgreSQL 然后调用 Debezium，它确认最新的 LSN 并允许数据库回收 WAL 空间。此任务可以通过heartbeat.action.query连接器配置属性自动执行。（此答案整理自Flink CDC 社区）