即使 Fivetran 連接器保持同步，RDS Postgres 最舊的複制延遲也會在不活動期間增加

我正在使用 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 heartbeat”**的解決方案，請參見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_lsnofpg_stat_replication都相同，也表明複製沒有滯後。

pg_replication_slots然而，在複製滯後圖中，儘管和pg_stat_replication並不表示滯後，但仍在增加。

為了進一步調試問題，我決定創建一個記錄以使數據庫上的一些活動在創建記錄後手動同步連接器。就在那時，我看到複製滯後急劇下降。見下圖。

基於這些觀察，我得出的結論是複制滯後正在增加，因為沒有同步更改，導致數據庫保持它的 WAL。

引用自：https://dba.stackexchange.com/questions/296289