作者：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/

相關推薦