在數字化時代的今天，我們都認同資料會創造價值，為了最大化資料的價值，我們不停的建立著資料遷移的管道，從同構到異構，從關系型到非關系型，從云下到云上，從數倉到資料湖，試圖在各種場景挖掘資料的價值，而在這縱橫交錯的資料網路中，邏輯復制扮演著及其重要的角色，
讓我們將視角從復雜的網路拉回其中的一個端點，從PostgreSQL出發，對其邏輯復制的原理進行解密，
1 概念與原理
邏輯復制，是基于復制標識復制資料及其變化的一種方法，區別于物理復制對頁面操作的描述，邏輯復制是對事務及資料元組的一種描述，
圖-WAL資料流示例
如圖所示，物理復制的資料流是對tablespace/database/filenode檔案的塊進行操作，而邏輯復制的內容是對元組進行描述，
接下來我們來看邏輯復制中的幾個概念：
復制槽
復制槽是記錄復制狀態的一組資訊，由于WAL（預寫式日志）檔案在資料真正落盤后會洗掉，復制槽會防止過早清理邏輯復制決議所需的WAL日志，在邏輯復制中，每個插槽從單個資料庫流式傳輸一系列更改，創建復制槽需要指定其使用的輸出插件，同時創建復制槽時會提供一個快照，
輸出插件
輸出插件負責將WAL日志解碼為可讀的格式，常用的插件用test_decoding(多用來測驗)，pgoutput（默認使用），wal2json（輸出為json），PostgreSQL定義了一系列回呼函式，我們除了使用上述插件，可以通過回呼函式撰寫自己的輸出插件，
圖-復制槽資料流
復制協議與訊息
通過復制協議，我們可以從源端獲取WAL資料流，例如通過PSQL工具建議復制連接
psql "dbname=postgres replication=database"
開啟流式傳輸WAL
START_REPLICATION[ SLOT slot_name] [ PHYSICAL] XXX/XXX[ TIMELINE tli]
無論是物理復制，還是邏輯復制，使用PostgreSQL的發布訂閱或者pg_basebackup搭建流復制，都是通過復制協議與定義的訊息進行互動（物理復制和邏輯復制資料流內容不同）
圖- WAL資料流訊息型別
圖-邏輯復制中的XLogData訊息
作業流程
當我們了解了概念之后，來看一下整個決議的作業流程，由于WAL檔案里一個事務的內容并不一定是連續的，所以需要通過Reorder后放在buffer中，根據事務ID組織成一條訊息，COMMIT后發送給輸出插件，輸出插件決議后將訊息流發送給目標端，
圖-邏輯決議作業流程
2 問題與演進
當我們掌握了邏輯復制的原理，計劃使用其構建我們的資料遷移應用之前，我們還有一些問題并沒有解決，讓我們來一起看看是什么亟待解決的問題，以及我們如何進行處理，
問題一：Failover slot
為了高可用性，資料庫至少會存在一主一備的架構，當主庫故障進行高可用切換時，備庫卻沒有相應的復制槽資訊，也就是缺少failover slot，這是由于保存slot資訊的物理檔案，未同步至備庫，那么我們如何手動創建一個faliover slot呢？
1. 主庫創建復制槽，檢查備庫wal檔案是否連續
2. 復制包含slot資訊的物理檔案至備庫，在pg_repslot目錄下
3. 備庫重啟，重啟后才可以看到復制槽資訊，原因是讀取slot物理檔案的函式StartupReplicationSlots只會在postmaster行程啟動時呼叫，
4. 定期查詢主庫slot狀態，使用pg_replication_slot_advance函式推進備庫復制槽
自此，我們在備庫上也有了相應的資訊，手動實作了failover slot，PostgreSQL生態中著名的高可用軟體Patroni也是以這種方式進行了實作，區別只是在Patroni查詢主庫slot狀態時將資訊寫入了DCS中，備庫拿到DCS中的位點資訊進行推進，
問題二：DDL同步
原生的邏輯復制不支持決議DDL陳述句，我們可以使用事件觸發器來進行處理，
1. 使用事件觸發器感知表結構變更，記錄到DDL_RECORD表中，并將該表通過邏輯復制進行發布，
2. 接收端獲取到該表的資料變更，即可處理為相應DDL陳述句進行執行，
圖-事件觸發器實作DDL同步
問題三： 雙向同步
當資料遷移涉及雙向同步的管道時，例如想實作雙主雙寫，對資料庫同一物件進行操作，就會出現WAL回圈，
圖-相同表雙向同步導致資料回圈
部分DTS應用為了解決這個問題會創建輔助表，在事務中先對輔助表進行操作，通過決議到對輔助表的操作而得知該記錄是又DTS應用插入，從而過濾該事務，不再回圈決議，PostgreSQL對事務提供了Origin記錄，無須輔助表，通過pg_replication_origin_session_setup函式或者發布訂閱中的replorigin_create即可指定Origin ID，
指定Origin ID后，我們除了可以決議后通過DTS應用進行過濾，還也可以通過決議插件中的FilterByOriginCB回呼函式在決議程序中過濾，這種方式減少了資料傳輸，效率更高，
圖-test_decoding中OriginFilter函式DEMO
其他問題：
除了以上三個問題，還有一些使用的問題或限制，這里列出了一些，不再展開，僅簡要說明，
Toast處理：對于toast值(訊息格式中可以判斷)，我們在處理時一般使用占位符進行處理，接收端接收到占位符就不對這一列進行處理，雖然有些麻煩，但這也是在和傳輸toast值的方案中權衡的結果，
心跳表：由于復制槽記錄的XMIN是全域的，當我們發布的表一直沒有更新時，XMIN沒有推進導致WAL積壓，我們可以創建一張心跳表，周期性寫入資料并發布，使XMIN進行推進，
大事務延遲： 根據前文提到的作業流程我們可以知道默認事務在COMMIT后才會進行決議，這對于大事務來說勢必會導致延遲，PG14版本提供了streamin模式進行決議，即事務進行中進行決議并發送至接收端，
3 應用與實踐
前兩節我們從原理及問題的角度對PostgreSQL進行了解密，接下來我們看如何通過我們掌握的邏輯復制原理，進行資料遷移的應用與實踐，
全量與增量同步
在真實的資料遷移場景中，大部分都是全量和增量都要同步的場景，并且我們打通了資料傳輸的通道后，也對這條通道的安全，效率，以及功能的擴展，例如清洗，脫敏等ETL能力提出了新的要求，我們先來看一下如果實作全量與增量的同步，
圖-資料流向示意圖
主要流程包括：
1. 創建復制槽并匯出快照
2. 根據快照進行全量資料遷移
3. 根據復制槽進行增量資料的遷移
我們使用了PG資料庫或者訊息佇列MQ作為資料代理，全量與增量決議可以同時進行，當全量資料處理完畢后，狀態機通知增量處理程式進行增量發布，而對于代理中的資料，可以在決議后進行預處理，
自建實體遷移上云實踐
最后和大家分享一個自建實體遷移上云的實踐，該案例是將自建的PG10版本實體遷移至京東云上的RDS PG 11版本，通過對增量資料的回流以及資料校驗保證了資料安全與業務平穩切換，
圖-資料遷移上云
DTS應用主要分為如下幾個階段：
1. 資料檢查階段： 檢查主鍵，權限，配置
2. 資料遷移階段： 結構，存量，增量資料遷移，監控遷移狀態
3. 應用遷移階段： 切換域名，引入流量
4. 回滾階段： 增量資料回流，若出現問題可快速回滾，
作者：蔣帥
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/509208.html
標籤：PostgreSQL