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

Jan*_*tel 3 postgresql replication amazon-rds postgresql-13

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

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

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

replication_log_size_staging_vs_ Fivetran_log

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

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

  • max_slot_wal_keep_size20000
  • rds.logical_replication1
  • wal_sender_timeout0(Fivetran 要求)

其余的配置都是默认的。

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

Jan*_*tel 7

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

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

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

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

复制日志大小固定

调试信息

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

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

当我检查restart_lsnconfirmed_flush_lsn时,pg_replication_slots它们都是相同的,表明复制没有滞后。

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

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

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

replication_log_size_drops_after_new_record_and_sync

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