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

Posted 2023-03-23

【中文标题】Debezium 导致 Postgres 耗尽 RDS 上的磁盘空间

【英文标题】：Debezium causes Postgres to run out of disk space on RDS

【发布时间】：2021-04-01 04:35:00

【问题描述】：

我有一个在 Amazon RDS 上运行的小型 Postgres 开发数据库，​​并且我正在运行 K8s。据我所知，几乎没有任何交通。 我想启用变更捕获，我启用了 rds.logical_replication，启动了一个 Debezium 实例，主题出现在 Kafka 中，一切看起来都很好。

几个小时后，可用磁盘空间开始减少：

它开始以恒定的速度消耗磁盘，并在 24 小时内耗尽所有可用的 20Gb。停止 Debezium 没有任何作用。我取回磁盘空间的方法是：

select pg_drop_replication_slot('services_debezium')

和：

vacuum full

然后，几分钟后，如图所示，磁盘空间被回收。

有什么建议吗？我很想看看到底是什么东西填满了这个空间，但我认为我做不到。 Debezium 方面似乎没有发生任何事情（没有不祥的日志），而且 Postgres 日志也没有显示任何特别之处。还是有一些外部事件触发了这个事件的开始？

【问题讨论】：

您终于找到原因/解决方法了吗？

据我了解，实例上有一个“不可见”的 AWS 数据库，它共享 WAL 并有相当多的活动。因此，如果更改捕获没有进行，无论是因为您的数据库上没有活动还是其他原因，它都会很快占用磁盘空间。当您的数据库活动很少时，设置心跳“heartbeat.interval.ms”会有所帮助。

【参考方案1】：

您需要定期在数据库中生成一些移动（例如，对任何记录执行更新）。

Debezium 提供了一种称为心跳的功能来执行这种类型的操作。

心跳可以在connector中配置如下：

"heartbeat.interval.ms" : "300000", "heartbeat.action.query": "update my_table SET date_column = now();"

您可以在官方文档中找到更多信息：

https://debezium.io/documentation/reference/connectors/postgresql.html#postgresql-wal-disk-space

【参考方案2】：

复制槽是问题所在。它在 WAL 中标记了一个位置，PostgreSQL 不会删除任何比该位置更新的 WAL 段。这些文件位于数据目录的pg_wal 子目录中。

删除复制槽并运行CHECKPOINT 将删除文件和可用空间。

问题的原因一定是 Debrezium 配置错误：它不消耗更改并将复制槽向前移动。解决这个问题，你就很好了。

【讨论】：

是的，但不是。奇怪的是，Debezium 运行良好：更改被消耗，延迟低，两边都没有错误。我很想看看文件系统上实际有什么，但是，AFAICT，亚马逊不允许这样做。而且这条线的笔直似乎表明它似乎与交通无关。我在日志中看到的唯一“可疑”内容是：“参数 max_wal_senders 设置为与复制不兼容的值。它已从 10 调整为 15。”

你不必相信我 :^)

【参考方案3】：

好吧，我想我明白了。 Amazon RDS 上还有另一个“隐藏”数据库，它有变化，但是我没有做的变化我可以看到，所以 Debezium 也无法获取它们。如果更改我监控的数据库，它将显示该更改并在此过程中刷新缓冲区并回收该空间。所以非常缺乏变化是它填满的原因。不知道是否有一个很好的解决方案，但至少我可以使用它。