即使 Fivetran 连接器保持同步，RDS Postgres 最旧的复制延迟在不活动期间也会增加

Question

我正在使用 Fivetran 作为 ETL 层来设置数据仓库。源数据库之一是 AWS RDS Postgres 实例。

我已将 Postgres 实例配置为使用 test_decoding 插件执行 WAL 的逻辑复制。在办公时间内一切似乎都工作正常，但是在办公时间之外，当没有执行查询时，最旧的复制槽滞后大小正在增加，尽管 Fivetran 连接器执行同步。

您可以在下图中看到这一点。在红色框中，复制槽滞后大小正在增加（上图），而同步时刻每小时都会发生（下图）。我期望出现如绿框中所示的图表，复制槽滞后大小在同步时刻周围正在减小。

我就这个问题联系了 Fivetran，但他们还无法找出问题所在，因此我向社区询问。

我使用 Postgres 版本 13.3 和以下自定义配置：

其余的配置都是默认的。

我还检查了其他问题，只有一个可能接近https://dba.stackexchange.com/a/103806/235086，但我不确定它是否适用于这里，因为它是关于秒数而不是大小的滞后。

Answer 1

我发现了这个问题，这是由于数据库不活动造成的。由于在办公时间之外数据库没有任何更改，因此副本（例如 Fivetran 连接器）不会消耗任何更改，因此 WAL 的 LSN 不会前进，并且复制延迟会增加。

似乎其他人也遇到了同样的问题，并提出了一种称为“WAL 心跳”的解决方案，请参阅1、2、3、4和5。这是一个重复的过程，例如 cron 作业，它在数据库中写入少量的虚拟数据以推进复制槽。

Fivetran 后来证实，他们也看到了这种行为，因此将于 2021 年第三季度推出 WAL 心跳支持。

因为 RDS 或 Fivetran 中还没有内置的 WAL 心跳支持。我已经实现了自己的实现，方法是创建一个重复的后台作业，每 15 分钟创建一条记录，例如 13:15、13:30、13:45。这解决了问题，如下图所示。部署修复程序后，我可以在通常没有活动的周末看到预期的鲨鱼牙齿。

调试信息

我还想分享我是如何调试它的。

我晚上一直醒着，看看复制延迟增加时会发生什么。当不活动开始时，我可以看到复制延迟增加。所以这证实了关于不活动的假设。

当我检查restart_lsn和confirmed_flush_lsn时，pg_replication_slots它们都是相同的，表明复制没有滞后。

此外，当连接器执行同步时，插槽变为活动状态，我可以看到和sent_lsn都是write_lsn相同pg_stat_replication的，也表明复制没有滞后。

然而，在复制滞后图中，尽管pg_replication_slots和并pg_stat_replication没有表明滞后，但仍在增加。

为了进一步调试问题，我决定创建一条记录以在数据库上进行一些活动，创建记录后我手动同步连接器。就在那时，我看到复制延迟急剧下降。参见下图。

根据这些观察，我得出的结论是，复制延迟正在增加，因为没有要同步的更改，导致数据库保留其 WAL。