DM 源碼閱讀系列文章（八）Online Schema Change 同步支持

做者：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 的邏輯處理流程：

1. 在操做目標數據庫上使用 create table ghost table like origin table 來建立 ghost 表；
2. 按照需求變動表結構，好比 add column/index；
3. gh-ost 自身變爲 MySQL replica slave，將原表的全量數據和 binlog 增量變動數據同步到 ghost 表；
4. 數據同步完成以後執行 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 模塊代碼實現以下：

• gh-ost 同步代碼實現
• pt-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 保存在內存中

下面是一個執行示例，方便你們對照着來理解上面的代碼邏輯：

1. Section 1： 使用 create table like statement 建立 ghost table，DM 會清空內存中 online_ddl._t2_gho 對應的 DDL 信息
2. Section 2： 執行 alter table statement，DM 會保存 DDL 到內存中
3. Section 3：trash table 的 DDLs 會被忽略
4. 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/