MySQL 5.7 DDL 与 GH-OST 对比分析

作者：来自 vivo 互联网存储研发团队- Xia Qianyong

本文首先介绍MySQL 5.7 DDL以及GH-OST的原理，然后从效率、空间占用、锁阻塞、binlog日志产生量、主备延时等方面，对比GH-OST和MySQL5.7 DDL的差异。

一、背景介绍

在 MySQL 数据库中，DDL（数据定义语言）操作包括对表结构、索引、触发器等进行修改、创建和删除等操作。由于 MySQL 自带的 DDL 操作可能会阻塞 DML（数据操作语言）写语句的执行，大表变更容易产生主备延时，DDL 变更的速度也不能控制，因此在进行表结构变更时需要非常谨慎

为了解决这个问题，可以使用 GitHub 开源的工具 GH-OST。GH-OST 是一个可靠的在线表结构变更工具，可以实现零宕机、低延迟、自动化、可撤销的表结构变更。相比于 MySQL 自带的 DDL 操作，GH-OST 可以在不影响正常业务运行的情况下进行表结构变更，避免了 DDL 操作可能带来的风险和影响。

通过使用 GH-OST工具，可以对 MySQL 数据库中的表进行在线结构变更，而不会对业务造成太大的影响。同时，GH-OST 工具还提供了多种高级特性，如安全性检测、自动化流程等，可以帮助用户更加高效地进行表结构变更。

二、MySQL5.7几种DDL介绍

2.1 copy

• server层触发创建临时表
• server层对源表加MDL锁,阻塞DML写、不阻塞DML读
• server层从源表中逐行读取数据，写入到临时表
• 数据拷贝完成后,升级字典锁，禁止读写
• 删除源表，把临时表重命名为源表

MySQL copy方式的DDL变更，数据表的重建(主键、二级索引重建)，server层作为中转把从innodb读取数据表，在把数据写到innodb层临时表。简单示意图如下：

2.2 inplace

（1）rebuild table

需要根据DDL语句创建新的表结构，根据源表的数据和变更期间增量日志，重建新表的主键索引和所有的二级索引。

Prepare阶段：

• 创建新的临时frm文件
• 持有EXCLUSIVE-MDL锁，禁止读写
• 根据alter类型，确定执行方式(copy,online-rebuild,online-norebuild)假如是Add Index，则选择online-norebuild
• 更新数据字典的内存对象
• 分配row_log对象记录增量
• 生成新的临时ibd文件

ddl执行阶段 :

• 降级EXCLUSIVE-MDL锁，允许读写
• 扫描old_table的聚集索引每一条记录rec
• 遍历新表的聚集索引和二级索引，逐一处理各个索引
• 根据rec构造对应的索引项
• 将构造索引项插入sort_buffer块排序
• 将sort_buffer块更新到新表的索引上
• 记录ddl执行过程中产生的增量(记录主键和索引字段)
• 重放row_log中的操作到新表索引商
• 重放row_log间产生dml操作append到row_log最后一个Block

commit阶段 :

• 当前Block为row_log最后一个时，禁止读写，升级到EXCLUSIVE-MDL锁
• 重做row_log中最后一部分增量
• 更新innodb的数据字典表
• rename临时idb文件，frm文件
• 增量完成

MySQL rebuild table方式的DDL，数据不需要通过sever层中转，innodb层自己完成数据表的重建。简单示意图如下：

（2）build-index

需要根据DDL语句创建新的表结构，根据源表的数据和变更期间增量日志，创建新的索引。

Prepare阶段 :

• 持有EXCLUSIVE-MDL锁，禁止读写
• 根据alter类型，确定执行方式(copy,online-rebuild,online-norebuild)
• 假如是Add Index，则选择online-norebuild
• 更新数据字典的内存对象
• 分配row_log对象记录增量

ddl执行阶段 :

• 降级EXCLUSIVE-MDL锁，允许读写
• 扫描old_table的聚集索引每一条记录rec
• 遍历新表的聚集索引,根据rec构造新的索引数据
• 将构造索引项插入sort_buffer块排序
• 将sort_buffer块更新到新表的索引上
• 记录ddl执行过程中产生的增量(仅记录主键和新索引字段)
• 重放row_log中的操作到新表索引上
• 重放row_log间产生dml操作append到row_log最后一个Block

commit阶段 :

• 当前Block为row_log最后一个时，禁止读写，升级到EXCLUSIVE-MDL锁
• 重做row_log中最后一部分增量
• 更新innodb的数据字典表
• 增量完成

MySQL rebuild index方式的DDL，数据不需要通过sever层中转，innodb层只需要完成变更二级索引的创建。简单示意图如下：

（3）only modify metadata

只修改元数据(.frm文件和数据字典)，不需要拷贝表的数据。

三、GH-OST

在GH-OST端，根据DDL语句创建新的表结构，根据源表的数据和增量期间增量日志，重建新表的主键索引和所有的二级索引，最终完成DDL增量。

主要流程如下：

• 根据DDL语句和源表创建新的表结构
• 根据唯一索引(主键索引或者其它唯一索引)

- 优先应用新增量的binlog到新的表中，需要经过GH-OST把binlog日志转换为sql，然后回放到影子表

- 其次拷贝源表中的数据到新的表中，表数据拷贝通过sql语句 insert ignore into (select .. from)直接在MySQL实例上执行，无需经过GH-OST中转

• 数据拷贝完成并应用完binlog后，通过lock table write 锁住源表
• 应用数据完成-获取到锁期间产生的增量binlog
• delete源表，rename影子表为源表，完成数据增量

GH-OST 进行DDL变更，GH-OST服务通知server层，server层作为中转把从innodb读取数据表，在把数据写到innodb层影子表。并且GH-OST作为中转读取DDL变更期间增量binlog解析成SQL写语句回放到影子表。简单示意图如下：

四、对比分析

DDL变更执行时长、对磁盘的额外占用(临时数据表+binlog)、锁阻塞时长、主备延时都是执行DDL变更人员比较关心的问题，本章将从从执行效率、占用表空间、锁阻塞、产生binlog日志量、主备延时等方面对MySQL原生的DDL和GH-OST进行对比分析。

4.1 执行效率

（1）only modify metadata(正常小于1S)

（2）build-index: 数据条目越多、新索引字段越大耗时越多

• 增量日志超过innodb_online_alter_log_max_size造成DDL失败

（3）rebuild table: 数据条目越多、所有索引字段之和越大耗时越多

• 增量日志超过innodb_online_alter_log_max_size造成DDL失败

（4）copy：数据条目越多，所有索引字段之和越大耗时越多，相对于rebuild table，数据需要从server层中转，所以比rebuild table耗时多

（5）GH-OST ：数据条目越多，所有索引字段之和越大耗时越多,

• 相对于copy，增量日志数据需要从GH-OST中转，所以比copy耗时多
• 有各种限流,(主备延时，threads超限延时…)，增加耗时
• 增量期间应用binlog速度如果跟不上业务产生binlog日志的速度，将无法完成增量
• critical 参数还会导致主动退出，例如thread_running

耗时：only modify metadata < build-index < build < copy < GH-OST

4.2 占用表空间

• 【only modify metadata】：忽略
• 【build-index】：额外需要，新增索引字段占用的空间
• 【rebuild-table】：额外需要约两倍的表空间
• 【copy】：额外需要约两倍的表空间
• 【GH-OST】 ：临时表占用约两倍的表空间，另外生成影子表会产生大量的binlog日志会占用表空间

占用表空间: only modify metadata < build-index < build = copy < GH-OST

4.3 锁阻塞

（1）only modify metadata

• DDL prepare阶段短暂的MDL排他锁，阻塞读写

（2）build-index table

• DDL prepare阶段短暂的MDL排他锁，阻塞读写
• 执行阶段(主要耗时阶段)，MDL SHARED_UPGRADABLE锁，不阻塞读写
• 执行阶段的最后会回放增量日志row_log，两个block间隙和最后block，持有源表索引的数据结构锁，会阻塞写
• 提交阶段，MDL锁升级为排他锁
• 回放剩余的row_log(执行完成致MDL锁升级期间新增的row_log，持有源表索引的数据结构锁，阻塞读写)

（3）rebuild-table: 和build-index table一致

（4）copy

• DDL prepare阶段短暂的MDL排他锁，阻塞读写
• 执行阶段(主要耗时阶段)，阻塞写，不阻塞读

（5）GH-OST

• 等待锁的时间也会阻塞业务
• 进入rename到拿表写锁的间隙有少量的新增binlog，后续需要持锁回放这部分日志
• rename表本身的耗时通常1s以内左右

锁阻塞时间：

only modify metadata=GH-OST < build-index table = rebuild-table  < copy(整个DDL期间都会阻塞业务的写)

锁阻塞分析：

MySQL DDL在获取MDL排它锁和GH-OST获取表的的写锁，在获取锁的等待期间都会阻塞业务的读写

• MySQL等待锁的超时时间为MySQL参数innodb_lock_wait_timeout。等待超时则失败
• GH-OST等待锁的时间，等待超时时间可配(默认6秒)，等待超时次数可配

4.4 产生binlog日志量

【MySQL5.7 DDL】: 在DDL执行结束时仅向binlog中写入一条DDL语句，日志量较小。

【GH-OST】: 影子表在全量数据拷贝和增量数据应用过程中产生大量的binlog日志(row模式)，对于大表日志量非常大。

产生binlog日志量：MySQL5.7 DDL < GH-OST

4.5 主备延时分析

（1）MySQL5.7 DDL：MySQL集群主备环境

• Master上DDL执行完成，binlog提交后，slave才开始进行DDL。
• slave串行复制、group复制模式,需要等前面的DDL回放完成后才会进行后续binlog回放，主备延时至少是DDL回放的时间。

（2）GH-OST：主备复制延时基本可以忽略

• GH-OST在master上创建一个影子表,在执行数据拷贝和binlog应用阶段，GHO表的binlog会实时同步到备。
• 影子表(_GHO表)应用完成后，通过rename实现新表切换，这个rename动作也会通过binlog传到salve执行完成DDL。

延时时间：GH-OST < MySQL DDL

备库执行DDL期间主库异常，主备切换。备库升级为主过程中，要回放完relaylog中的DDL和dml，才能对外服务，否则会出现数据丢失，这将造成业务较长时间的阻塞。

4.6 总结

GH-OST 工具和 MySQL 原生 DDL 工具的适用场景不同，具体使用哪种工具需要根据实际需求进行选择。

• 变更人员无法判断本次DDL是否会造成DML阻塞、锁阻塞等，建议使用GH-OST工具。
• 如果需要进行在线表结构变更，并且需要减少锁阻塞时间、减少主备延时等问题，建议使用 GH-OST 工具。
• 变更只涉及到元数据的修改，建议使用mysql原生DDL。
• 如果表结构变更较小，对锁阻塞时间和主备延时要求不高，建议使用 MySQL 原生 DDL 工具。

参考资料：

• online DDL Operations
• MySQL · 源码阅读 · 白话Online DDL
• 【腾讯云CDB】源码分析·MySQL online ddl日志回放解析 
• GH-OST一些使用限制
• mysql mdl锁类型