PostgreSQL的邏輯複製對比物理複製的好處總結有如下幾點
微信
1 靈活: 邏輯複製對比物理複製來講,能夠單表進行數據的複製,物理複製則是不能夠的,而且大部分時間對於ETL的功能需求來講,物理複製過重了,須要的磁盤,網絡,等資源都相對於邏輯複製消耗的要大的多. 網絡
2 方便:邏輯複製相對於物理複製,設置會更簡單,能夠隨時終止或者建立,數據進行同步等等.架構
3 定製化:邏輯複製能夠設置複製的操做,例如只須要進行insert 的複製,或者 update, delete 等操做的複製,能夠作到, 數據不和primary端一致,而達到某些目的..net
4 數據遷移,PG若是版本不一樣進行升級的狀況下,PG的logical replication 是能夠做爲一種數據遷移的方案,在不一樣的版本中進行數據的同步使用的.3d
邏輯複製仍是使用物理複製架構實現,從上圖可見, 在複製槽的基礎上添加了pgoutput plugin 將原有的wal 日誌轉換後發送, subscription 在接受這些信息,將信息填充到目的地. 爲了不數據被重複的在subscription 上重複操做,經過客戶端記錄接受的LSN號碼,避免重複接受一樣的數據,並操做.
日誌
另外須要提示的是,不少不能進行vacuum的案例中,部分都有複製槽的出現,可能這個複製槽一主多用,同時有數據接收端,其中若是有數據接收端沒法接受數據,則與相關的須要保留的tuples 就不會被清理,形成 vacuum 沒法回收.
blog
下面咱們有一個複製槽
ip
而後咱們人爲的製造一個衝突. 在數據複製的從庫,將數據表的人爲添加了一條數據.
資源
在subscription 端查看subscription 的信息
get
而後咱們在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 空間出現問題,最終致使主庫磁盤空間耗盡的問題.
本文分享自微信公衆號 - AustinDatabases（AustinDatabases）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。