簡介 CloudCanal 實現了對 Online DDL 工具如 GH-OST 和 PT-OSC 的支持，保證了對端實時同步源端的 Online DDL 操作。 本文以 MySQL -> MySQL 同步鏈路使用 GH-OST 為例，介紹 CloudCanal 是如何支持實時同步 GH-OST 產 ...
簡介
CloudCanal 實現了對 Online DDL 工具如 GH-OST 和 PT-OSC 的支持，保證了對端實時同步源端的 Online DDL 操作。
本文以 MySQL -> MySQL 同步鏈路使用 GH-OST 為例，介紹 CloudCanal 是如何支持實時同步 GH-OST 產生的 DDL 的。
Online DDL 技術背景
市面上常用的兩款MySQL Online DDL 工具分別是 GH-OST 和 PT-OSC，CloudCanal 對他們都做了相容處理使得用戶可以實時同步 Online DDL 工具產生的 DDL 。下麵簡單介紹下他們的工作流程，以便於讀者理解後續章節的內容。
Online DDL 工具 PT-OSC 原理
PT-OSC 是較為常用的 Online DDL 工具，通過觸發器來同步增量數據，相較於 MySQL 原生的 Online DDL 性能得到了極大的提高，原理如下：
- 對源表進行檢查
- 創建一個與源表（origin）結構一致的空表，命名為 _origin_new
- 根據alter參數修改新表的表結構
- 在源表中創建三個觸發器：Delete / Update / Insert，將源表中的增刪改語句同步執行到新表中，同時將源表中的數據以數據塊的形式 copy 到新表
- 將源表（origin）rename為 _origin_old，將 _origin_new rename 為 origin，然後刪除舊表（可選）
- 刪除觸發器
總結：PT-OSC 是通過創建臨時表，並用觸發器將增量數據同步到新表，通過當前讀和事務來實現增量與全量的有序，不會阻塞讀寫操作，但運行過程中出現異常，無法從上一個位置繼續進行，需要從頭開始。
Online DDL 工具 GH-OST 原理
GH-OST 也是一款常用的 Online DDL 工具，採用讀取 binlog 日誌的方式來同步增量數據，原理如下：
- 對源表（origin）進行檢查
- 在主/從節點中添加binlog日誌監聽
- 創建日誌記錄表（_origin_ghc）和與源表結構一致的影子表（_origin_gho）
- 根據alter參數修改影子表的表結構
- 全量拷貝源表數據同時拷貝源表增量數據到影子表中，並記錄日誌到日誌記錄表中
- 刪除日誌記錄表，將源表改名為 _origin_del, 將影子表改名為 origin，_origin_del 可選刪除
總結： GH-OST 的性能與 PT-OSC 相近，相較於PT-OSC 的優點就在於其是不使用觸發器的，只非同步讀取二進位日誌，因此修改表定義的負載和正常的業務負載解耦開了，它不需要考慮被修改的表上的併發操作和競爭等，並且相較於 PT-OSC 的中斷從頭開始，GH-OST 可以從心跳日誌中恢復到指定位置。
CloudCanal 技術點
前文中對 Online DDL 工具的原理中我們知道，無論採用哪種 Online DDL 工具，源端都會產生一些臨時表的創建和數據寫入，如果不做任何相容處理，這會影響正常的遷移同步鏈路。
因此為了支持 GH-OST 和 PT-OSC 工具的使用，CloudCanal 在 MySQL 源端做了大量優化，完美的適配並優化了 GH-OST 和 PT-OSC 的 Online DDL 能力
同步臨時表數據
GH-OST 和 PT-OSC 工具都有一個共同的特點，其原理都是採用臨時表的方式來保證 DDL 與 DML 的併發操作。
CloudCanal 預設的表訂閱模式是只訂閱原表，不訂閱與原表相關的臨時表（訂閱表即同步該表的 DDL 與 DML 語句），而 CloudCanal 為了滿足對 Online DDL 工具的支持，在源數據端配置上新增了 extraDDL 參數來實現對臨時表的訂閱。
- extraDDL參數：
- 可選參數：NONE / GHOST / PT
- 作用：選擇 NONE 則不訂閱任何臨時表，選擇 GHOST / PT 則訂閱相應的預設臨時表
CloudCanal 針對臨時表訂閱採用的是兩種模式：自動訂閱臨時表模式和自動同步元數據模式
- 自動訂閱臨時表：CloudCanal 會自動根據 extraDDL 參數將預設的臨時表加入到訂閱表集合中，隨後讀取binlog日誌時將不會過濾掉臨時表的所有變更事件，保證了對端數據源表結構與數據的最終一致性
- 自動同步元數據：CloudCanal 會自動過濾臨時表，在讀取binlog日誌時不會執行 Online DDL 的操作，在 Online DDL 執行完畢後發送最新的表結構，期間的 DML 語句也會同步發送到對端，保證對端數據源表結構與數據的最終一致性
由於各數據源對同步數據的消費並不相同，如消息隊列只需要解析 Online DDL 後的表結構即可，無需訂閱臨時表，因此我們需要根據對端數據源的消費模式做出不同的處理。
DDL 解析與轉換
不同數據源的 DDL 語句會有所差異，CloudCanal 對不同數據源 DDL 語句的解析和轉換做了大量的優化。
- 解析：將 DDL 語句解析為操作類型，如 CREATE ，DROP，ALTER 等
- 拆分過濾：若 DDL 語句不為單條操作，則拆分為多條 DDL 語句，根據訂閱表集合和binlog位點記錄過濾重覆執行的 DDL 語句與去除無需同步的語句後，重新合成新的 DDL 語句
- 轉換：將過濾好的 DDL 語句轉換為對端數據源的方言
下圖演示了CloudCanal對DDL語句的一些處理:
容錯機制
當 CloudCanal 在同步 Online DDL 時，任務有可能在兩個層面上被中斷：Online DDL 工具層面和 CloudCanal任務層面
-
Online DDL 工具中斷：由於 PT-OSC 和 GH-OST 的原理不同，Online DDL 過程中斷的恢復方案也有所不同
- PT-OSC：Online DDL 過程中出現異常中斷，重新執行 Online DDL 操作會丟棄之前的所有操作，從頭開始再次執行
- GH-OST：Online DDL 過程中出現異常中斷，重新執行 Online DDL 操作會讀取ghc日誌心跳錶，從日誌中的未完成位點開始繼續執行。在此過程中，CloudCanal只需讀取binlog日誌，照常執行 Online DDL 的所有操作即可保證數據的最終一致性
-
CloudCanal任務中斷：由於 CloudCanal 良好的非同步消費特性，CloudCanal的任務中斷與 Online DDL 的執行並不相關。當 CloudCanal 任務中斷後，重啟任務會根據位點記錄繼續執行binlog日誌中的事件，保證了數據的最終一致性。
使用示例
前置條件
CREATE TABLE `ghost_test`.`abc` (
`id` int NOT NULL,
`name` varchar(30) DEFAULT NULL,
`cdata` datetime DEFAULT NULL,
`udata` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
- 登錄 CloudCanal 平臺 ，添加源端與目標端數據源
任務創建
- 任務管理 -> 任務創建。
- 測試連接並選擇 源 和 目標 資料庫。
- 選擇增量同步任務和需要訂閱的表與欄位，並創建任務
- 增量任務中，功能列表 -> 參數修改 -> 源數據源配置 -> 參數 extraDDL 設置為 GHOST
創建並且啟動任務，當任務正常執行到增量階段時，此時我們可以利用數據生成工具和Online DDL工具對源端資料庫觸發一些增量DML變更和DDL變更，然後查看CloudCanal是否能正常實時同步這些DML和DDL事件。
使用 Online DDL 工具修改表結構
- 首先使用數據生成工具實時隨機生成數據，增刪改比例為（4：4：3）
- 在大量寫入數據的同時，使用 GH-OST 工具執行 DDL 語句：ALTER TABLE ADD COLUMN aaa VARCHAR(30) NOT NULL AFTER id。在我們的測試例子中，有 DML 語句的同時使用 GH-OST 執行 DDL 語句，源端總計寫入14147 條數據和1條DDL。
[root@zjx local] ./gh-ost --debug --user="｛資料庫用戶名｝" --password="｛資料庫密碼｝" --host="｛資料庫主機IP｝" --port="｛資料庫埠號｝" --database="ghost_test" --table="abc" --initially-drop-ghost-table --initially-drop-old-table --allow-on-master --alter="ADD COLUMN aaa varchar(30) NOT NULL AFTER id" --execute
確認同步結果
CloudCanal會自動完成源端實時DML和DDL事件的同步，在執行完源端事件寫入之後，我們確認下同步結果。
- 更改後的源對端 表結構一致
- 源對端進行數據校驗 數據一致
總結：由上可知，在 CloudCanal 中使用 GH-OST 工具執行 Online DDL 指令，源表完成表結構修改後，CloudCanal 將源表的表結構成功同步到了目標端數據表中。
常見問題
CloudCanal 支持的同步鏈路
目前 CloudCanal 支持使用 Online DDL 工具的鏈路為：
- MySQL -> MySQL
- MySQL -> PostgreSQL
- MySQL -> Greenplum
- MySQL -> Kafka
- MySQL -> RocketMQ
- MySQL -> RabbitMQ
不支持同步的 DDL 語句
使用 Online DDL 工具執行的 DDL 語句中不支持 RENAME 原表與臨時表的操作，如上述用例中，ALTER 語句若改為 RENAME TABLE ghost_test.abc TO ghost_test.ccc，那麼 Online DDL 工具後續的 RENAME TABLE ghost_test.abc TO ghost_test._abc_del, ghost_test._abc_gho TO ghost_test.abc 操作就會失敗，致使 Online DDL 操作失敗。
總結
本文主要介紹了 Online DDL 工具的使用並展示了 CloudCanal 對 Online DDL 工具的實時同步能力，得益於 GH-OST、PT-OSC 優秀的表結構修改性能和 CloudCanal 強大的同步能力，基本能滿足企業在日常執行 DDL 的業務中，數據表的 DML 執行和數據同步性能要求
