簡介
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日志中的事件，保證了資料的最終一致性，
使用示例
前置條件
- 安裝 GH-OST
- 登入 CloudCanal SaaS版，使用參見 快速上手檔案
- 準備一個 MySQL 資料庫，對端資料庫（以 MySQL -> MySQL 為例）
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 執行和資料同步性能要求
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/541025.html
標籤：其他
上一篇：大資料 - DWS層 業務實作