PostgreSQL邏輯復制數據不一致導致主庫wal log無限增大怎么辦

本篇文章為大家展示了PostgreSQL邏輯復制數據不一致導致主庫wal log無限增大怎么辦，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

PostgreSQL的邏輯復制對比物理復制的好處總結有以下幾點

1 靈活: 邏輯復制對比物理復制來說,可以單表進行數據的復制,物理復制則是不可以的,并且大部分時間對于ETL的功能需求來說,物理復制太重了,需要的磁盤,網絡,等資源都相對于邏輯復制消耗的要大的多. 

2 方便:邏輯復制相對于物理復制,設置會更簡單,可以隨時終止或者創建,數據進行同步等等.

3 定制化:邏輯復制可以設置復制的操作,例如只需要進行insert 的復制,或者 update, delete 等操作的復制,可以做到, 數據不和primary端一致,而達到某些目的.

4 數據遷移,PG如果版本不同進行升級的情況下,PG的logical replication 是可以作為一種數據遷移的方案,在不同的版本中進行數據的同步使用的.

邏輯復制還是使用物理復制架構實現,從上圖可見, 在復制槽的基礎上添加了pgoutput plugin 將原有的wal 日志轉換后發送, subscription 在接受這些信息,將信息填充到目的地. 為了避免數據被重復的在subscription 上重復操作,通過客戶端記錄接受的LSN號碼,避免重復接受同樣的數據,并操作.

另外需要提示的是,很多不能進行vacuum的案例中,部分都有復制槽的出現,可能這個復制槽一主多用,同時有數據接收端,其中如果有數據接收端無法接受數據,則與相關的需要保留的tuples 就不會被清理,造成 vacuum 無法回收.

下面我們有一個復制槽

然后我們人為的制造一個沖突. 在數據復制的從庫,將數據表的人為添加了一條數據.

在subscription 端查看subscription 的信息

然后我們在publication 端也插入數據

直接進入到subscription 中查看錯誤日志

系統一直在報錯的狀態中, 由于主庫和從庫之間的數據操作沖突,導致從主庫到從庫的數據無法被操作. 那到底是怎么影響了WAL log

我們繼續往下看

在主庫我們將2000條數據刪除1900條

在subscription 中我們查看當前的數據,結果一定是和主庫已經脫離,不會在繼續進行任何操作,主要的原因也是 邏輯復制是有順序的,如果任何一個操作被卡主,則后續的操作都不會被完成.

那么后續主庫的 latest checkpoint location 的進度將停止,無論你做任何的操作,或者使用checkpoint 命令 也不會影響

這里如果PG_WAL 無法進行checkpoint 則表明PG的WAL LOG 無法歸檔,隨著主庫的操作越來越多,則WA了的文件也會越來越大,無法進行清理.

下面我們在從庫中將自行添加的記錄刪除后,在看主庫的checkpoint location 

已經變化了. 

當然如何監控replication logical 復制是否中斷的問題

select   pid, client_addr, state, sync_state,  

         pg_wal_lsn_diff(sent_lsn, write_lsn) as write_lag,  

         pg_wal_lsn_diff(sent_lsn, flush_lsn) as flush_lag,  

         pg_wal_lsn_diff(sent_lsn, replay_lsn) as replay_lag

from pg_stat_replication;

如果你當前有一個replication 的情況下, 查詢主庫,如果復制正常,則會查出你與subscription之間的情況, 如果數據不一致,造成復制停止的情況,則再次查詢就不會有數據顯示了.  所以這也是一個判斷邏輯復制是否正常的一個方式方法.

邏輯復制停止會造成主庫的wal 無法截斷的問題,所以如果PG 已經使用了邏輯復制,則必須對邏輯復制進行監控,否則在繁忙的業務系統中,邏輯復制的停止,會讓你的主庫的wal 空間出現問題,最終導致主庫磁盤空間耗盡的問題.

上述內容就是PostgreSQL邏輯復制數據不一致導致主庫wal log無限增大怎么辦，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。