PostgreSQL 邏輯複製"水」好深
- 2019 年 10 月 5 日
- 筆記
邏輯複製，就是那個容易出錯，效率低，容易造成主從數據不一致的技術. 可能在提及邏輯複製，就會得到上面的評論，或許是MYSQL 給人的第一印象（其實我不認為邏輯複製有多不好）。當然對比物理複製 Stream Replication 來說，邏輯的複製的效率的確是不高，並且上面被吐槽的地方都是有的。
但邏輯複製有什麼好
1 我只要XX 庫的數據 ，或XX表的數據，物理複製可以嗎？
2 我要做匯聚庫，要 XX 庫表 XX 庫表 到 一個庫中，進行數據分析？
3 誒，我複製的庫的數據，可能的改改，在從庫上改改試試，那我改的時候你就別在複製了，我改完做完測試後，在還原我剛才改的數據，你在繼續複製OK ？
4 誒，我們要將目前的PG 10 的表複製到PG 11
那物理複製——– NO WAY
所以一項技術的好壞先要看他是否能滿足需求，所以邏輯複製好不好要看他是否能滿足上面的需求。
OK 我們先來將一個測試庫導入到 PG 的數據庫中，大家如果測試可以使用dvdrental 庫作為 simple 庫。
我們舉例下面就是我們要操作的數據庫 dvdrental 中包含了15個表
1 我們將dvdrental 整體數據庫中的所有的表都複製到另一個PG的服務器中。
1 創建一個publication,在 dvdrental 數據庫中執行如下命令創建一個 dvdrental 為命名的所有表的 publication
CREATE PUBLICATION dvdrental FOR ALL TABLES;
2 對源數據庫進行備份，採用 pg_dump pg_resotre 來進行（不清楚的同學請百度一下，很簡單）
3 在將源數據庫恢復到了目的庫的 dvdrental 庫後
CREATE SUBSCRIPTION publication CONNECTION 'host=192.168.198.200 dbname=dvdrental user=publication password=1234.com port=5432' PUBLICATION dvdrental;
然後我們可以查看當前複製是否被建立。
select * from pg_stat_replication;
看上去還是比較簡單的，但上面的操作有以下幾個問題
1 我備份的數據是整體備份數據, 還原到目的庫，還是僅僅備份表結構然後讓主從邏輯去同步數據。
這個問題的兩方面看
1 邏輯備份不需要你備份數據庫，只要有表結構即可，並且表結構也不要求是一定和原表的表結構一致，只要是不比原表的字段少，類型大致一致即可。
2 那既然邏輯備份可以補足數據，為什麼還要進行備份數據的工作，在恢復到目的地，這裡有一個問題，就是數據量的問題，如果數據量比較啊，則數據補足的時間會比較慢，所以可以先備份數據過去，在進行複製。
但這裡又有一個問題，如果我在備份的時候帶有數據，到目的地，在建立複製，是否有數據丟失的情況，因為我在備份恢復的過程中，也有數據寫入。
帶着這個問題我們做下一個實驗
1 我建立一個publication
2 我備份數據庫
3 期間我添加數據在publication端
4 我恢複數據庫
5 建立subscription查看 在3 好期間的數據是否能補齊
最後的結果是，不能補齊，這和我試想的是一樣的，首先我們建立publication 的時候，並沒有建立複製槽，而複製槽的建立，是開始數據複製的開始, 所以在複製槽建立前如果在publication端錄入的數據，並且在 subscription 端創建訂閱時 採用 with (copy_data = false) 那必然是不會有複製槽建立前備份後錄入的數據。
但如果我們不實用 copy_data = false 則在同步數據的時候，要不就等待的時間較長，（如果數據量足夠大，publication端的 wal_log 的目錄會保留很多來不及進行複製的數據操作記錄），並且還會有很多重複主鍵的錯誤提示，因為複製是從頭開始的，通過主鍵的方式，而備份的數據必然和部分publication的數據重合，但數據是不會丟失的。
這是一點，在做邏輯複製時需要考慮的問題
另一個點是，我在做測試的時候很怪異，我想停止訂閱服務，
alter subscription 訂閱的名字 disable
提示 訂閱不存在
drop subscription 訂閱的名字
刪除訂閱 也提示訂閱不存在
無奈之下只能關閉從庫，刪除publication 和 複製槽
而留下的結果也很有趣，就是連續做了兩次 publication subscription 會出現同樣名字的subscription的殘留，並且嘗試刪除也失敗。
到目前為止，邏輯複製還有一些問題需要搞清楚，在學習的過程中，發現有些怪異的問題並未有明確的文檔或者解釋，包含英文方面的也目前也未找到特別詳細的內容。
