自 PostgreSQL 9.4 ，終于支持了邏輯流復制。本篇文章為大家帶來這部分的技術細節的分析。 ## 1\. 背景 PostgreSQL 9.4 對邏輯流復制的支持具有相當的意義。我們可以用該技術完成很多企業級的需求。 1. PostgreSQL 的大版本升級，由于可以使用流復制做增量數據同步，所以停機服務時間會非常短。 2. PostgreSQL 自定義邏輯拆庫。由于是邏輯數據，所以很容易自定義分發規則。例如按表拆，邏輯分表，白名單，黑名單等等。 3. PostgreSQL 增量同步到其他異構數據庫，例如 PG 同步到 Mysql；PG 同步到 Oracle。 4. 邏輯主備同步，邏輯多節點同時可寫集群。 ## 2\. 名詞解析 | Logical Decoding | PostgreSQL 的邏輯日志來源于解析物理 WAL 日志。 解析 WAL 成為邏輯數據的過程叫 Logical Decoding。 | | Replication Slots | 保存邏輯或物理流復制的基礎信息。類似 Mysql 的位點信息。 一個 邏輯 slot 創建后，它的相關信息可以通過 pg_replication_slots 系統視圖獲取。 如果它在 active 狀態，則可以通過系統視圖 pg_stat_replication 看到一些 slot 的實時的狀態信息。 | | Output Plugins | PostgreSQL 的邏輯流復制協議開放一組可編程接口，用于自定義輸數據到客戶端的邏輯數據的格式。 這部分實現使用插件的方式被內核集成和使用，稱作 Output Plugins。 | | Exported Snapshots | 當一個邏輯流復制 slot 被創建時，系統會產生一個快照。客戶端可以通過它訂閱到數據庫任意時間點的數據變化。 | ## 3\. 邏輯流復制輸出的數據格式 Logical Decoding 是把 WAL 日志解析成邏輯日志的過程。這個過程輸出的是數據格式可以描述為： 1. 事物開始 任何的變化總是在一個事物中，所以訂閱的數據變化的開始是是一個事物被啟動的消息，他包括了事物 ID，LSN，開始時間等信息。 2. 數據的變化 包括當前事物中修改的數據。即對某些表的 insert update delete 操作來帶的數據變化。 * 一個事物內可以包含任意個表和任意行數據的變化。 * 輸出的數據的格式和對應表的定義和索引相關，詳細信息看后面文章的描述。 3. 事物的提交 包括事物提交的 LSN，時間等相關信息。 ## 4\. Output Plugins 需要完成的工作 上一節的內容提到的數據需要通過 Output Plugins 確定最終的數據格式，再發送給客戶端。 這部分的接口表現為下列回調函數： 1. LogicalDecodeStartupCB startup_cb; 2. LogicalDecodeBeginCB begin_cb; 3. LogicalDecodeChangeCB change_cb; 4. LogicalDecodeCommitCB commit_cb; 5. LogicalDecodeShutdownCB shutdown_cb; 函數 1，5 是分配和清理插件所需的內存結構。此外的 2，3，4 三個回調函數完全對應上一節中的三個部分。 開發者可以根據需求實現這一組函數。 ### 4.1 技術細節 毫無疑問，定制邏輯數據格式成為了 Output Plugins 的關鍵。根據不同的需求產生的數據也會有顯著的不同。 1. 發送的數據可以是普通字符串，也可以是二進制字符串。為了客戶端解析數據更容易，通常使用二進制字符串表達數據。 2. 如果做同構數據庫數據同步，傳輸的數據可以比較簡單。原因是可以使用內部數據直接表達變化的數據。 3. 如果要做異構數據庫同步，情況會復雜一些。目前的方案是把增量數據組合成通用 SQL，再寫入到異構數據庫中。這樣就需要給出轉換數據成 SQL 語句的所有信息。在變化的數據本身外，還需要包括表名，列名，列數據類型，索引信息等等。 4. 針對不同數據庫的特殊字符，還需要處理轉譯字符的問題。 5. 針對表中的長字段，需要優化。如果不修改這些大字段，可以選擇不傳輸它們。 ### 4.2 REPLICA IDENTITY 如何影響數據的格式 邏輯流復制利用索引的方式優化傳輸數據的效率，它們可以按表為單位定制。大致分為三種情況: 1. 如果修改的表有 primary key, 則表的變化的邏輯數據只會包括該表變化的列和pk列數據，如果 pk 列被修改，則還會輸出老的 pk 列數據。 2. 如果修改的表沒有 primary key，則可以使用 alter table 指定一個 REPLICA index，同時需要這個索引列為非空，其產生的效果和 1 相同。 3. 如果修改的表不滿足上面的兩個條件，而又要做同步，可以使用 alter table 設置這個表的 REPLICA IDENTITY 為 FULL。于是系統在表修改時會記錄修改行的所有列，不會做任何的優化。 很明顯，給對應的表設置 PK 或指定索引，在數據同步時效率更高。我們可以安需定制同步策略。在實現功能的過程中需要考慮這部分變化。 ## 5\. 總結 邏輯流復制特性對 PostgreSQL 意義重大，目前已經有很多相關的數據同步產品應運而生，比如 2nd quadrant 公司的 BDR/UDR。也有公司調整了已有產品原有的技術方案，使用邏輯流復制為增量數據的同步方案，比如 EDB 公司的 xDB。阿里云 RDS 團隊也利用該特性推出了 PostgreSQL 的數據遷移服務，并且開源了相關代碼。 最后，我們期待更多相關產品的出現。 謝謝！