我有一个小型的Postgres开发数据库运行在Amazon RDS上，并且我运行的是K8。据我所知，几乎没有任何流量。我想启用更改捕获，我启用了rds. logical_replication，启动了一个Debezium示例，主题出现在Kafka中，一切似乎都很好。
几个小时后，可用磁盘空间开始减少：
它开始以恒定的速度消耗磁盘空间，并在24小时内耗尽所有可用的20GB。停止Debezium没有任何作用。我恢复磁盘空间的方法是：
select pg_drop_replication_slot('services_debezium')以及：
vacuum full然后，几分钟后，如图所示，磁盘空间被回收。
有什么提示吗？我很想看看到底是什么东西填满了这个空间，但我不认为我能做到。Debezium方面似乎没有发生任何事情（没有不祥的日志），Postgres日志也没有显示任何特别的东西。或者是有什么外部事件触发了这个开始？
3条答案
按热度按时间qojgxg4l1#
您需要定期在数据库中生成一些移动（例如，对任何记录执行更新）。
Debezium提供了一个称为heartbeat的特性来执行这种类型的操作。
可以在连接器中配置心跳信号，如下所示：
“heartbeat.interval.ms“：“300000”，“心跳.动作.查询”：“更新我的表SET日期列=现在（）;“
您可以在官方文档中找到更多信息：
https://debezium.io/documentation/reference/connectors/postgresql.html#postgresql-wal-disk-space
x8goxv8g2#
问题出在复制槽上，它在WAL中标记了一个位置，PostgreSQL不会删除任何比这个位置更新的WAL段，这些文件位于data目录的
pg_wal子目录中。删除复制槽并运行
CHECKPOINT将删除文件并释放空间。您可能还必须删除VACUUM (FULL)表，这些表在VACUUM无法取得任何进展时变得臃肿。问题的原因一定是Debrezium配置错误：它不会消耗更改，并将复制插槽向前移动。解决这个问题，您就很好了。
wz8daaqr3#
好的，我想我已经知道了。Amazon RDS上还有另一个“隐藏”数据库，它有更改，但这些更改不是我做的，我可以看到，所以Debezium也不能发现它们。如果更改我监控的数据库，它会显示更改，并在此过程中刷新缓冲区并回收该空间。因此，非常缺乏更改是它充满的原因。不要“I don“我不知道是否有一个很好的解决办法，但至少我可以用这个办法。