作者：lan
本文爲 DM 源碼閱讀系列文章的第八篇，上篇文章 對 DM 中的定製化數據同步功能進行詳細的講解，包括庫表路由（Table routing）、黑白名單（Black & white table lists）、列值轉化（Column mapping）、binlog 過濾（Binlog event filter）四個主要功能的實現。
本篇文章將會以 gh-ost 爲例，詳細地介紹 DM 是如何支持一些 MySQL 上的第三方 online schema change 方案同步，內容包括 online schema change 方案的簡單介紹，online schema change 同步方案，以及同步實現細節。
MySQL 的 Online Schema Change 方案
目前有一些第三方工具支持在 MySQL 上面進行 Online Schema Change，比較主流的包括 pt-online-schema-change 和 gh-ost。
這些工具的實現原理比較類似，本文會以 gh-ost 爲例來進行分析講解。
從上圖可以大致瞭解到 gh-ost 的邏輯處理流程：
- 在操作目標數據庫上使用
create table ghost table like origin table來創建 ghost 表； - 按照需求變更表結構，比如
add column/index； - gh-ost 自身變爲 MySQL replica slave，將原表的全量數據和 binlog 增量變更數據同步到 ghost 表；
- 數據同步完成之後執行
rename origin table to table_del, table_gho to origin table完成 ghost 表和原始表的切換
pt-online-schema-change 通過 trigger 的方式來實現數據同步，剩餘流程類似。
在 DM 的 task 配置中可以通過設置 online-ddl-scheme 來配置的 online schema change 方案，目前僅支持 gh-ost/pt 兩個配置選項。
DM Online Schema Change 同步方案
根據上個章節介紹的流程，pt 和 gh-ost 除了 replicate 數據的方式不一樣之外，其他流程都類似，並且這種 native 的模式可以使得 binlog replication 幾乎不需要修改就可以同步數據。但是 DM 爲了減少同步的數據量，簡化一些場景（如 shard tables merge）下的處理流程，並做了額外的優化，即，不同步 ghost 表的數據。
繼續分析 online schema change 的流程，從數據同步的角度看有下面這些需要關注的點：
- 原始表的增量數據同步模式有沒有變化
- ghost 表會產生跟原始表幾乎一樣的冗餘 binlog events
- 通過
rename origin table to table_del, table_gho to origin table完成 ghost 表和原始表的切換
如果使用 ghost 表的 alter DDL 替換掉 rename origin table to table_del, table_gho to origin table ，那麼就可以實現我們的不同步 ghost 表數據的目的。
DM Online Schema Change 同步實現細節
Online schema change 模塊代碼實現如下：
DM 將 同步的表分爲三類：
- real table - 原始表
- trash table - online schema change 過程中產生的非關鍵數據表，比如以
_ghc,_del爲後綴的表 - ghost table - 與原始表對應的經過 DDL 變更的數據表，比如以
_gho爲後綴的表
當 DM 遇到 DDL 的時候，都會 調用 online schema change 模塊的代碼進行處理，首先判斷表的類型，接着針對不同類型作出不同的處理：
- real table - 對 rename table statement 進行模式檢查，直接返回執行
- trash table - 對 rename table statement 做一些模式檢查，直接忽略同步
-
ghost table
- 如果 DDL 是 create/drop table statement ，則 清空內存中的殘餘信息後忽略這個 DDL 繼續同步
- 如果 DDL 是 rename table statement ，則 返回內存中保存的 ghost table 的 DDLs
- 如果是其他類型 DDL，則把這些 DDL 保存在內存中
下面是一個執行示例，方便大家對照着來理解上面的代碼邏輯：
- Section 1： 使用 create table like statement 創建 ghost table，DM 會清空內存中
online_ddl._t2_gho對應的 DDL 信息 - Section 2： 執行 alter table statement，DM 會保存 DDL 到內存中
- Section 3：trash table 的 DDLs 會被忽略
- Section 4：遇到 ghost table 的 rename table statement 會替換成 Section 2 的 DDL, 並且將該 DDL 的 table name 更換成對應 real table name 去執行
注意： rename table statement 模式檢查主要是爲了確保在 online schema change 變更過程中除了 rename origin table to table_del, table_gho to origin table 之外沒有其他 rename table statement，避免同步狀態的複雜化。
小結
本篇文章詳細地介紹 DM 對 online schema change 方案的同步支持，內容包含 online schema change 方案的簡單介紹， online schema change 同步方案，以及同步實現細節。下一章會對 DM 的 shard DDL merge 方案進行詳細的講解，敬請期待。
原文閱讀：
https://www.pingcap.com/blog-cn/dm-source-code-reading-8/
