作者: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,比较主流的包括 pt-online-schema-change 和 gh-ost。
这些工具的实现原理比较类似,本文会以 gh-ost 为例来进行分析讲解。
从上图可以大致了解到 gh-ost 的逻辑处理流程:
create table ghost table like origin table
来创建 ghost 表;add column/index
;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 两个配置选项。
根据上个章节介绍的流程,pt 和 gh-ost 除了 replicate 数据的方式不一样之外,其他流程都类似,并且这种 native 的模式可以使得 binlog replication 几乎不需要修改就可以同步数据。但是 DM 为了减少同步的数据量,简化一些场景(如 shard tables merge )下的处理流程,并做了额外的优化,即,不同步 ghost 表的数据。
继续分析 online schema change 的流程,从数据同步的角度看有下面这些需要关注的点:
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 表数据的目的。
Online schema change 模块代码实现如下:
DM 将 同步的表分为三类:
_ghc
, _del
为后缀的表_gho
为后缀的表当 DM 遇到 DDL 的时候,都会 调用 online schema change 模块的代码进行处理,首先判断表的类型,接着针对不同类型作出不同的处理:
下面是一个执行示例,方便大家对照着来理解上面的代码逻辑:
online_ddl
._t2_gho
对应的 DDL 信息注意: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/