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/