Jan*_*tel 3 postgresql replication amazon-rds postgresql-13
我正在使用 Fivetran 作为 ETL 层来设置数据仓库。源数据库之一是 AWS RDS Postgres 实例。
我已将 Postgres 实例配置为使用 test_decoding 插件执行 WAL 的逻辑复制。在办公时间内一切似乎都工作正常,但是在办公时间之外,当没有执行查询时,最旧的复制槽滞后大小正在增加,尽管 Fivetran 连接器执行同步。
您可以在下图中看到这一点。在红色框中,复制槽滞后大小正在增加(上图),而同步时刻每小时都会发生(下图)。我期望出现如绿框中所示的图表,复制槽滞后大小在同步时刻周围正在减小。
我就这个问题联系了 Fivetran,但他们还无法找出问题所在,因此我向社区询问。
我使用 Postgres 版本 13.3 和以下自定义配置:
max_slot_wal_keep_size
:20000
rds.logical_replication
:1
wal_sender_timeout
:0
(Fivetran 要求)其余的配置都是默认的。
我还检查了其他问题,只有一个可能接近https://dba.stackexchange.com/a/103806/235086,但我不确定它是否适用于这里,因为它是关于秒数而不是大小的滞后。
我发现了这个问题,这是由于数据库不活动造成的。由于在办公时间之外数据库没有任何更改,因此副本(例如 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。
归档时间: |
|
查看次数: |
4510 次 |
最近记录: |