技术分享 | gh-ost 在线 ddl 变动工具

做者简介：
杨奇龙，网名“北在南方”，7年DBA老兵，目前任职于杭州有赞科技DBA，主要负责数据库架构设计和运维平台开发工做，擅长数据库性能调优、故障诊断。

1、前言

做为 MySQL DBA，相信咱们你们都会对大表变动（大于10G 以上的）比较头疼，尤为是某些 DDL 会锁表，影响业务可持续性。目前通用的方案使用 Percona 公司开源的 pt-osc 工具解决致使锁表的操做，还有一款 github 基于 go 语言开发的 gh-ost。本文主要介绍 gh-ost 使用方法，其工做原理放到下一篇文章介绍。

2、使用

2.1 gh-ost 介绍

gh-ost 做为一个假装的备库，能够从主库/备库上拉取 binlog，过滤以后从新应用到主库上去，至关于主库上的增量操做经过 binlog 又应用回主库自己，不过是应用在幽灵表上。

其大体的工做过程：

1. gh-ost 首先链接到主库上，根据 alter 语句建立幽灵表，
2. 而后做为一个备库链接到其中一个真正的备库或者主库上(根据具体的参数来定)，一边在主库上拷贝已有的数据到幽灵表，一边从备库上拉取增量数据的 binlog，而后不断的把 binlog 应用回主库。
3. 等待所有数据同步完成，进行 cut-over 幽灵表和原表切换。图中 cut-over 是最后一步，锁住主库的源表，等待 binlog 应用完毕，而后替换 gh-ost 表为源表。gh-ost 在执行中，会在本来的 binlog event 里面增长如下 hint 和心跳包，用来控制整个流程的进度，检测状态等。

固然 gh-ost 也会作不少前置的校验检查，好比 binlog_format，表的主键和惟一键，是否有外键等等
这种架构带来诸多好处，例如：

整个流程异步执行，对于源表的增量数据操做没有额外的开销，高峰期变动业务对性能影响小。
下降写压力，触发器操做都在一个事务内，gh-ost 应用 binlog 是另一个链接在作。
可中止，binlog 有位点记录，若是变动过程发现主库性能受影响，能够马上中止拉binlog，中止应用 binlog，稳定以后继续应用。
可测试，gh-ost 提供了测试功能，能够链接到一个备库上直接作 Online DDL，在备库上观察变动结果是否正确，再对主库操做，内心更有底。不过不推荐在备库直接操做。

2.2 gh-ost 操做模式

a. 链接到从库，在主库作迁移
这是 gh-ost 默认的工做方式。gh-ost 将会检查从库状态，找到集群结构中的主库并链接，接下来进行迁移操做：

1. 行数据在主库上读写
2. 读取从库的二进制日志，将变动应用到主库
3. 在从库收集表格式，字段&索引，行数等信息
4. 在从库上读取内部的变动事件（如心跳事件）
5. 在主库切换表

若是你的主库的日志格式是 SBR，工具也能够正常工做。但从库必须启用二级制日志( log_bin,log_slave_updates) 而且设置 binlog_format=ROW 。

b. 链接到主库
直接链接到主库构造 slave，在主库上进行 copy 数据和应用 binlog，经过指定 --allow-on-master 参数便可。固然主库的 binlog 模式必须是 row 模式。

c. 在从库迁移/测试
该模式会在从库执行迁移操做。gh-ost 会简单的链接到主库，此后全部的操做都在从库执行，不会对主库进行任何的改动。整个操做过程当中，gh-ost 将控制速度保证从库能够及时的进行数据同步

--migrate-on-replica 表示 gh-ost 会直接在从库上进行迁移操做。即便在复制运行阶段也能够进行表的切换操做。
--test-on-replica 表示 迁移操做只是为了测试在切换以前复制会中止，而后会进行切换操做，而后在切换回来，你的原始表最终仍是原始表。两个表都会保存下来，复制操做是中止的。你可>以对这两个表进行一致性检查等测试操做。

3、实践

https://github.com/github/gh-ost

3.1 参数说明：

这里列出比较重要的参数，你们能够经过以下命令获取比较详细的参数以及其解释。

gh-ost --help
-allow-master-master:
是否容许gh-ost运行在双主复制架构中，通常与-assume-master-host参数一块儿使用
-allow-nullable-unique-key:
容许gh-ost在数据迁移依赖的惟一键能够为NULL，默认为不容许为NULL的惟一键。若是数据迁移(migrate)依赖的惟一键容许NULL值，则可能形成数据不正确，请谨慎使用。
-allow-on-master:
容许gh-ost直接运行在主库上。默认gh-ost链接的从库。
-alter string:
DDL语句
-assume-master-host string:
为gh-ost指定一个主库，格式为”ip:port”或者”hostname:port”。在这主主架构里比较有用，或则在gh-ost发现不到主的时候有用。
-assume-rbr:
确认gh-ost链接的数据库实例的binlog_format=ROW的状况下，能够指定-assume-rbr，这样能够禁止从库上运行stop slave,start slave,执行gh-ost用户也不须要SUPER权限。
-chunk-size int:
在每次迭代中处理的行数量(容许范围：100-100000)，默认值为1000。
-concurrent-rowcount:
该参数若是为True(默认值)，则进行row-copy以后，估算统计行数(使用explain select count(*)方式)，并调整ETA时间，不然，gh-ost首先预估统计行数，而后开始row-copy。
-conf string:gh-ost的配置文件路径。
-critical-load string:
一系列逗号分隔的status-name=values组成，当MySQL中status超过对应的values，gh-ost将会退出。-critical-load Threads_connected=20,Connections=1500，指的是当MySQL中的状态值Threads_connected>20,Connections>1500的时候，gh-ost将会因为该数据库严重负载而中止并退出。
-critical-load-hibernate-seconds int :
负载达到critical-load时，gh-ost在指定的时间内进入休眠状态。它不会读/写任何来自任何服务器的任何内容。
-critical-load-interval-millis int:
当值为0时，当达到-critical-load，gh-ost当即退出。当值不为0时，当达到-critical-load，gh-ost会在-critical-load-interval-millis秒数后，再次进行检查，再次检查依旧达到-critical-load，gh-ost将会退出。
-cut-over string:
选择cut-over类型:
atomic/two-step，atomic(默认)类型的cut-over是github的算法，two-step采用的是facebook-OSC的算法。
-cut-over-exponential-backoff
-cut-over-lock-timeout-seconds int:
gh-ost在cut-over阶段最大的锁等待时间，当锁超时时，gh-ost的cut-over将重试。(默认值：3)
-database string:
数据库名称。
-default-retries int:
各类操做在panick前重试次数。(默认为60)
-dml-batch-size int:

在单个事务中应用DML事件的批量大小（范围1-100）（默认值为10）

-exact-rowcount:

准确统计表行数(使用select count(*)的方式)，获得更准确的预估时间。

-execute:

实际执行alter&migrate表，默认为noop，不执行，仅仅作测试并退出，若是想要ALTER TABLE语句真正落实到数据库中去，须要明确指定-execute

-exponential-backoff-max-interval int

-force-named-cut-over:
若是为true，则'unpostpone | cut-over'交互式命令必须命名迁移的表
-heartbeat-interval-millis int:
gh-ost心跳频率值，默认为500
-initially-drop-ghost-table:
gh-ost操做以前，检查并删除已经存在的ghost表。该参数不建议使用，请手动处理原来存在的ghost表。默认不启用该参数，gh-ost直接退出操做。
-initially-drop-old-table:
gh-ost操做以前，检查并删除已经存在的旧表。该参数不建议使用，请手动处理原来存在的ghost表。默认不启用该参数，gh-ost直接退出操做。
-initially-drop-socket-file:
gh-ost强制删除已经存在的socket文件。该参数不建议使用，可能会删除一个正在运行的gh-ost程序，致使DDL失败。
-max-lag-millis int:
主从复制最大延迟时间，当主从复制延迟时间超过该值后，gh-ost将采起节流(throttle)措施，默认值：1500s。
-max-load string:
逗号分隔状态名称=阈值，如：'Threads_running=100,Threads_connected=500'. When status exceeds threshold, app throttles writes
-migrate-on-replica:
gh-ost的数据迁移(migrate)运行在从库上，而不是主库上。
-nice-ratio float:
每次chunk时间段的休眠时间，范围[0.0…100.0]。0：每一个chunk时间段不休眠，即一个chunk接着一个chunk执行；1：每row-copy 1毫秒，则另外休眠1毫秒；0.7：每row-copy 10毫秒，则另外休眠7毫秒。
-ok-to-drop-table:
gh-ost操做结束后，删除旧表，默认状态是不删除旧表，会存在_tablename_del表。
-panic-flag-file string:
当这个文件被建立，gh-ost将会当即退出。
-password string :
MySQL密码
-port int ：
MySQL端口，最好用从库
-postpone-cut-over-flag-file string：
当这个文件存在的时候，gh-ost的cut-over阶段将会被推迟，数据仍然在复制，直到该文件被删除。
-skip-foreign-key-checks:
肯定你的表上没有外键时，设置为'true'，而且但愿跳过gh-ost验证的时间-skip-renamed-columns ALTER
-switch-to-rbr:
让gh-ost自动将从库的binlog_format转换为ROW格式。
-table string:
表名
-throttle-additional-flag-file string:
当该文件被建立后，gh-ost操做当即中止。该参数能够用在多个gh-ost同时操做的时候，建立一个文件，让全部的gh-ost操做中止，或者删除这个文件，让全部的gh-ost操做恢复。
-throttle-control-replicas string:
列出全部须要被检查主从复制延迟的从库。
-throttle-flag-file string:
当该文件被建立后，gh-ost操做当即中止。该参数适合控制单个gh-ost操做。-throttle-additional-flag-file string适合控制多个gh-ost操做。
-throttle-query string:
节流查询。每秒钟执行一次。当返回值=0时不须要节流，当返回值>0时，须要执行节流操做。该查询会在数据迁移(migrated)服务器上操做，因此请确保该查询是轻量级的。
-timestamp-old-table:
在旧表名中使用时间戳。这会使旧表名称具备惟一且无冲突的交叉迁移。
-user string :MYSQL用户

3.2 执行 ddl

测试例子对 test.b 重建表 alter table b engine=innodb；

/opt/gh-ost/bin/gh-ost \
--max-load=Threads_running=20 \
--critical-load=Threads_running=50 \
--critical-load-interval-millis=5000 \
--chunk-size=1000 \
--user="root" \
--password="" \
--host='127.0.0.1' \
--port=3316 \
--database="test" \
--table="b" \
--verbose \
--alter="engine=innodb" \
--assume-rbr \
--cut-over=default \
--cut-over-lock-timeout-seconds=1 \
--dml-batch-size=10 \
--allow-on-master \
--concurrent-rowcount \
--default-retries=10 \
--heartbeat-interval-millis=2000 \
--panic-flag-file=/tmp/ghost.panic.flag \
--postpone-cut-over-flag-file=/tmp/ghost.postpone.flag \
--timestamp-old-table \
--execute 2>&1 | tee  /tmp/rebuild_t1.log

操做过程当中会生成两个中间状态的表 _b_ghc, _b_gho，其中 _b_ghc 是记录 gh-ost 执行过程的表，其记录相似以下：

_b_gho 是目标表，也即应用 ddl 语句的幽灵表。

特别说明，上面的命令实际上是在咱们的生产线上直接使用的。通常咱们针对几百 G 的大表作归档删除数据以后要重建表，以便减小表空间大小。重建完，进行 cut-over 切换幽灵表和原表时，默认不删除幽灵表。由于直接删除上百 G 会对磁盘 IO 有必定的影响.
其余的请各位同行根据本身的状况去调整合适的参数，注意如下两个参数。

--ok-to-drop-table:gh-ost操做结束后，删除旧表，默认状态是不删除旧表，会存在_tablename_del表。
--timestamp-old-table 最终rename的时候表名会加上时间戳后缀，每次执行的时候都会生成一个新的表名。

3.3 gh-ost 的特性

gh-ost 拥有众多特性，好比：轻量级、可暂停、可动态控制、可审计、可测试等等，咱们能够经过操做特定的文件对正在执行的 gh-ost 命令进行动态调整。

暂停/恢复
咱们能够经过建立/删除 throttle-additional-flag-file 指定的文件 /tmp/gh-ost.throttle 控制 gh-ost 对 binlog 应用。

限流
gh-ost 能够经过 unix socket 文件或者 TCP 端口（可配置）的方式来监听请求，DBA 能够在命令运行后更改相应的参数，参考下面的例子：
打开限流

echo throttle | socat - /tmp/gh-ost.test.b.sock

_b_ghc 中会多一条记录

331 | 2019-08-31 23:23:00 | throttle at 1567264980930907070 | done throttling

关闭限流

no-throttle | socat - /tmp/gh-ost.test.b.sock

_b_ghc 中会多一条记录

347 | 2019-08-31 23:24:09 | throttle at 1567265049830789079 | commanded by user

改变执行参数：chunk-size= 1024, max-lag-millis=100, max-load=Thread_running=23 这些参数均可以在运行时动态调整。

echo chunk-size=1024 | socat - /tmp/gh-ost.test.b.sock
echo max-lag-millis=100 | socat - /tmp/gh-ost.test.b.sock
echo max-load=Thread_running=23 | socat - /tmp/gh-ost.test.b.sock

终止运行
咱们经过来过建立 panic-flag-file 指定的文件，当即终止正在执行的 gh-ostmin
建立文件 /tmp/ghost.panic.flag

gh-ost log提示

2019-08-31 22:50:52.701 FATAL Found panic-file /tmp/ghost.panic.flag. Aborting without cleanup

注意中止 gh-ost 操做会有遗留表 xxx_ghc，xxx_gho还有 socket 文件，管理 cut-over 的文件，若是你须要执行两次请务必检查指定目录是否存在这些文件，而且清理掉文件和表。

4、与 pt-osc 的对比

从功能，稳定性和性能上来看，两种工具各有千秋，虽然在高并发写的状况下，gh-ost 应用 binlog 会出现性能较低不如 pt-osc 的状况。不过 gh-ost 更灵活，支持咱们根据实际状况动态调整。
推荐两个 blog 的文章吧，你们能够根据本身的实际场景去选择使用哪一个工具。
https://www.cnblogs.com/zping...
https://blog.csdn.net/poxiaon...

5、总结

整体来说 gh-ost 是一款很是出色的开源产品，感谢 github 为咱们 MySQL DBA 提供了一种解决大表 ddl 的工具，欢迎还没使用的朋友试用该工具。

参考文章
https://www.cnblogs.com/zhouj...
https://segmentfault.com/a/11...