postgresql Debezium导致Postgres耗尽RDS上的磁盘空间

ecfsfe2w  于 2023-03-01  发布在  PostgreSQL
关注(0)|答案(3)|浏览(163)

我有一个小型的Postgres开发数据库运行在Amazon RDS上,并且我运行的是K8。据我所知,几乎没有任何流量。我想启用更改捕获,我启用了rds. logical_replication,启动了一个Debezium示例,主题出现在Kafka中,一切似乎都很好。
几个小时后,可用磁盘空间开始减少:

它开始以恒定的速度消耗磁盘空间,并在24小时内耗尽所有可用的20GB。停止Debezium没有任何作用。我恢复磁盘空间的方法是:

select pg_drop_replication_slot('services_debezium')

以及:

vacuum full

然后,几分钟后,如图所示,磁盘空间被回收。
有什么提示吗?我很想看看到底是什么东西填满了这个空间,但我不认为我能做到。Debezium方面似乎没有发生任何事情(没有不祥的日志),Postgres日志也没有显示任何特别的东西。或者是有什么外部事件触发了这个开始?

qojgxg4l

qojgxg4l1#

您需要定期在数据库中生成一些移动(例如,对任何记录执行更新)。
Debezium提供了一个称为heartbeat的特性来执行这种类型的操作。
可以在连接器中配置心跳信号,如下所示:
“heartbeat.interval.ms“:“300000”,“心跳.动作.查询”:“更新我的表SET日期列=现在();“
您可以在官方文档中找到更多信息:
https://debezium.io/documentation/reference/connectors/postgresql.html#postgresql-wal-disk-space

x8goxv8g

x8goxv8g2#

问题出在复制槽上,它在WAL中标记了一个位置,PostgreSQL不会删除任何比这个位置更新的WAL段,这些文件位于data目录的pg_wal子目录中。
删除复制槽并运行CHECKPOINT将删除文件并释放空间。您可能还必须删除VACUUM (FULL)表,这些表在VACUUM无法取得任何进展时变得臃肿。
问题的原因一定是Debrezium配置错误:它不会消耗更改,并将复制插槽向前移动。解决这个问题,您就很好了。

wz8daaqr

wz8daaqr3#

好的,我想我已经知道了。Amazon RDS上还有另一个“隐藏”数据库,它有更改,但这些更改不是我做的,我可以看到,所以Debezium也不能发现它们。如果更改我监控的数据库,它会显示更改,并在此过程中刷新缓冲区并回收该空间。因此,非常缺乏更改是它充满的原因。不要“I don“我不知道是否有一个很好的解决办法,但至少我可以用这个办法。

相关问题