Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >gh-ost 在线ddl变更工具​

gh-ost 在线ddl变更工具​

作者头像
用户1278550
发布于 2019-09-03 12:11:45
发布于 2019-09-03 12:11:45
1.1K00
代码可运行
举报
文章被收录于专栏:idbaidba
运行总次数:0
代码可运行

一 前言

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

二 使用

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 将会检查从库状态,找到集群结构中的主库并连接,接下来进行迁移操作:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
行数据在主库上读写

读取从库的二进制日志,将变更应用到主库

在从库收集表格式,字段&索引,行数等信息

在从库上读取内部的变更事件(如心跳事件)

在主库切换表

如果你的主库的日志格式是 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 表示 迁移操作只是为了测试在切换之前复制会停止,然后会进行切换操作,然后在切换回来,你的原始表最终还是原始表。两个表都会保存下来,复制操作是停止的。你可以对这两个表进行一致性检查等测试操作。

三 实践

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

3.1 参数说明:

这里列出比较重要的参数,大家可以通过如下命令获取比较详细的参数以及其解释。

gh-ost --help

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
-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.0100.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.t1 重建表 alter table t1 engine=innodb;

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
/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有一定的影响. 其他的请各位同行根据自己的情况去调整合适的参数,注意以下两个参数。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
--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 这些参数都可以在运行时动态调整。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
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的文件,如果你需要执行两次请务必检查指定目录是否存在这些文件,并且清理掉文件和表

四 与pt-osc的对比

从功能,稳定性和性能上来看,两种工具各有千秋,虽然在高并发写的情况下,gh-ost 应用binlog会出现性能较低不如pt-osc的情况。不过gh-ost更灵活,支持我们根据实际情况动态调整。

推荐两个blog的文章吧,大家可以根据自己的实际场景去选择使用哪个工具。

https://www.cnblogs.com/zping/p/8876148.html

https://blog.csdn.net/poxiaonie/article/details/75331916

五 总结

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-09-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 yangyidba 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Online DDL 工具 gh-ost实战(一)
2020年了,开始正文前,先说几句废话,2019年公众号开始正式更文,后期由于个人问题停更了,2020年开始重新开始更文,更文目的很简单,记录自己的学习,分享给大家,就这么简单;好啦,言归正传,下面开始今天的正文了;
SEian.G
2021/03/03
2.3K0
技术分享 | Online DDL 工具 gh-ost
爱可生 DBA 团队成员,负责公司 DMP 产品的运维和客户 MySQL 问题的处理。擅长数据库故障处理。对数据库技术和 python 有着浓厚的兴趣。
爱可生开源社区
2020/08/05
1.2K0
技术分享 | Online DDL 工具 gh-ost
MySQL在线DDL工具 gh-ost
gh-ost基于 golang 语言,是 github 开源的一个 DDL 工具,是 GitHub's Online Schema Transmogrifier/Transfigurator/Transformer/Thingy 的缩写,意思是 GitHub 的在线表定义转换器。
东山絮柳仔
2021/03/18
1.8K0
gh-ost 学习笔记
https://m.aliyun.com/yunqi/articles/62928
保持热爱奔赴山海
2019/09/17
1.2K0
gh-ost 学习笔记
gh-ost:在线DDL修改MySQL表结构工具
在之前,我分享过一次 pt-online-schema-change 在线 DDL 的工具实践记录,在实际使用过程中,发现部门的很多老系统大量使用了触发器,从而无法使用这个工具,非常遗憾!导致很多 DDL 变更都必须压到空闲时候做,比如凌晨,非常苦逼。 咨询了做 DBA 的老同事,他将 gh-ost 推荐给我,基于 golang 语言,是 github 开源的一个 DDL 工具,gh-ost 是 gitHub,s Online Schema Transmogrifier/Transfigurator/Tra
张戈
2018/03/26
6.6K2
gh-ost:在线DDL修改MySQL表结构工具
MySQL DDL Online Schema Change—gh-ost介绍
gh-ost是针对MySQL对主库影响很小,无trigger的online schema change解决方案。采用消费binlog的方式来代替trigger方式,并将同步信息存储到临时表中。
MySQL轻松学
2019/12/05
1.4K0
MySQL 最佳实践:gh-ost 工具使用详解
MySQL 的同步机制比较单纯,主库上执行过的 DML 和 DDL 会在从库上再执行一次,那么主库上需要 10min 才能执行完的 DDL 理论上在从库至少也要花费 10min 才能执行完,这意味着从库的同步会延迟 10min 以上,等 DDL 执行完之后才会继续追同步。
王文安@DBA
2020/07/30
10.4K0
MySQL 最佳实践:gh-ost 工具使用详解
MYSQL 修改表结构 gh-ost 到底强哪里 作者自己来talk
PT工具在MYSQL中的使用其实已经好像有“半个世纪了”,其出名的原因主要是因为pt-osc,如果你不知道,那你真的用过MYSQL,其实还有另外两家 FB-OST , GH-OST.
AustinDatabases
2020/03/26
8750
MYSQL 修改表结构 gh-ost 到底强哪里 作者自己来talk
gh-ost工具Online-ddl简单操作记录
主从架构 192.168.175.206 主 192.168.175.207 从 192.168.175.208 从 ghost配置文件(可以不加) 在207上添加 [root@localhost ~]# vi ghost.conf [client] user=mha password=123 命令如下 [root@test-206 ~]# gh-ost --assume-master-host='192.168.175.206:3306' --master-user='mha' --master-p
shynodes
2021/07/28
6800
gh-ost工具Online-ddl简单操作记录
MySQL Online DDL经典工具-gh-ost
Online DDL一直是MySQL数据库的一个痛点,好在官方和社区都有不错的解决方案。这些方案大致有以下几个:
DBA札记
2023/11/16
5210
MySQL Online DDL经典工具-gh-ost
MySQL Online DDL
serena
2017/06/01
8K0
MySQL Online DDL
MySQL DDL发展史
- 注意: 在online ddl前,inplace的方法主要在第三步大大缩短了时间,只重构了索引,没有重新copy所有数据
划水教练
2022/05/17
1.1K0
MySQL DDL发展史
Online DDL 工具 gh-ost原理(二)
接上一篇文章Online DDL 工具 gh-ost实战(一),介绍了gh-ost的实际使用案例,本文介绍一下gh-osh的相关原理;
SEian.G
2021/03/03
7790
MySQL 拜托加个索引能和PG一样简单吗? 只能gh-ost了 烦人
MySQL MySQL 怎么那么烦人,好用,好用个屁。用过数据库吗说好用,加个索引都那么的费劲。说到这里我很想用宋丹丹老师那句,怎么那么烦人来结束此篇文章,在给MYSQL一个大白眼,和SQL SERVER ORACLE 比不了,和 PG也比不了,人家仨都有在线索引的技术,虽然SQL SERVER 黑,必须买企业版,但人家有。MySQL 呵呵
AustinDatabases
2024/06/04
1460
gh-ost 原理剖析
上一篇文章 介绍 gh-ost 参数和具体的使用方法,以及核心特性-可动态调整 暂停,动态修改参数等等。本文分几部分从源码方面解释gh-ost的执行过程,数据迁移,切换细节设计。
用户1278550
2019/09/24
2.3K0
gh-ost 原理剖析
Mysql onlineddl vs gh-ost
Innodb早期支持通过copy table跟inplace的方式来执行DDL语句,其原理如下:
mingjie
2022/05/12
8610
Mysql onlineddl vs gh-ost
MySQL 表 DDL 操作全攻略
MySQL 千万级表因为上述相关的一些问题,需要进行 DDL 操作时,由于其锁表特性可能引发诸多严重问题:
蝉羽
2024/11/25
2750
GitHub开源的MySQL在线更改Schema工具
好雨社区原创翻译 MySQL在线更改schema的工具很多,如Percona的pt-online-schema-change、 Facebook的 OSC和 LHM等,但这些都是基于触发器(Trigg
Rainbond开源
2018/05/31
2.2K0
技术分享 | Online DDL 工具 pt-osc
爱可生 DBA 团队成员,主要负责 MySQL 故障处理和公司自动化运维平台维护。对技术执着,为客户负责。
爱可生开源社区
2020/09/23
5K0
技术分享 | Online DDL 工具 pt-osc
技术分享 | 实测在 after_sync 中使用 gh-ost是如何丢数据的
最近,IMG 的姜老师发布了一篇关于使用 gh-ost 会丢数据的文章(gh-ost 翻车!使用后导致数据丢失!),大致结论就是:在 MySQL AFTER_SYNC的 场景下,使用 gh-ost 进行表结构变更(包括最新 GA 的1.1.2版本在内),可能会导致数据丢失,还引起大家在微信群内展开了一些讨论。得知这个消息,还是觉得有些意外的,毕竟对于大部分 DBA 来说,gh-ost 属于比较常用的 DDL 工具,会用其替代 pt-osc 或 MySQL 自带的 online ddl 。出于好奇,去 gh-ost 的 Gtihub 主页上看了下,还真有相关的 issue ,并且已经有人提交了 fix 的 PR (目前该 fix 尚未得到官方回应)
爱可生开源社区
2021/11/11
1.1K0
技术分享 | 实测在 after_sync 中使用 gh-ost是如何丢数据的
相关推荐
Online DDL 工具 gh-ost实战(一)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验