1. 为什么大表换表结构让人这么头疼搞过MySQL的人应该都体会过那种感觉线上订单表几个亿的数据某天业务说要加个字段或者DBA巡检发现某个常用查询缺索引想加一个索引结果一评估上千万行的表直接ALTER TABLE可能要跑几十分钟甚至几个小时中间业务完全不可用这种操作在核心库上简直等于一场小型灾难。先说说原生DDL在大表上的真实表现。MySQL在早期版本执行ALTER TABLE时实际上是新建一张临时表把旧表数据一行一行复制过去复制完成后把旧表删掉再把新表改名顶上。听起来流程挺合理但它最大的问题在于复制过程中默认情况下会对原表加锁阻塞所有写入。即使从MySQL 5.6开始引入了online DDL支持某些操作在复制数据的同时允许并发DML但一些底层场景——比如需要重建表的操作、改变列类型、修改字符集——依然会非常耗时而且在线日志、锁资源消耗都可能成为瓶颈。更关键的是数据量一大复制本身带来的IO和主从延迟已经够受的了业务高峰期根本不敢碰。很多团队因此转向了pt-online-schema-change通常简称pt-osc这类基于触发器的工具。它通过在原表上创建触发器来捕获增量变更然后把数据复制到影子表最后交换表名。这套方案确实解决了不少问题但触发器本身对主库有额外的写入开销而且触发器容易和已有的触发器冲突在繁忙的库上性能打折的情况不少。再说如果原来表上已经有触发器pt-osc默认就会拒绝执行兼容性处理起来很烦。我自己的亲身经历是某次想在核心交易表上给一个流水号字段加索引表有大约1.4T行数超过8亿正常DDL评估下来乐观估计要三四个小时而且期间全程不能接受写阻塞。试过pt-osc但那张表本身挂了两个业务触发器没法直接用。最后我们用gh-ost跑通了整个变更全程业务无感主库几乎没抖动这件事给我留下了非常深的印象。从那以后凡是核心库的大表变更我基本都优先考虑gh-ost。gh-ost是GitHub开源的一款无触发器在线表结构变更工具。它取名自GitHubs Online Schema Transmogrifier看起来像ghost但其实是缩写演变用Go语言写成单二进制文件部署不需要额外安装。和pt-osc不同它完全不走触发器而是用binlog来捕获增量数据再通过类似主从复制的方式把旧表的数据源源不断同步到影子表。它的好处是可以在变更过程中动态控制速度、暂停甚至完全回滚并且对主库和从库的压力更可控。这篇东西适合谁看如果你是需要在生产库里做表结构变更的DBA、运维工程师或者后端开发想了解大表DDL的解决方案那这篇会非常对口。我会把gh-ost的原理、前置条件、实操流程、限速方式、常见坑全部梳理出来基本是我自己几年实操下来的经验整理不是简单抄文档的复读机式教程。2. gh-ost到底是怎么偷梁换柱的理解了gh-ost解决了什么问题下一步得搞清楚它内部是怎么运转的。很多人用工具只记命令不搞懂原理一旦出问题就抓瞎。我建议至少花十分钟把它的核心机制过一遍后面排查问题的时候会省无数时间。2.1 三条并行的处理链路gh-ost的核心思路可以概括为八个字影子表、binlog追平、原子换表。它在启动后主要做三件事inspector日志探测连接连接到一个实例通常是从库也可以是主库读取binlog事件并且实时获取主库当前的最新binlog坐标。applier数据同步连接连接到主库创建一张影子表表名通常类似_yourtable_gho结构是变更后的版本。随后它把旧表中的历史数据分批复制到这张影子表里。binlog listener日志监听连接监听前面inspector抓到的binlog事件把DML操作insert/update/delete按原样应用到影子表上。这三条链路是并行的历史数据在搬增量变更在追日志在持续监听。整个过程有点像流量从一条老水管改道到一条新水管既要抽干老管道里的存量水又要保证水管改道期间新流进来的水也全部进新管道一条都不能漏。关键点在于gh-ost是靠binlog来实现增量捕获的这意味着所有要变更的表必须开启ROW格式的binlog而且参数binlog_row_image默认就是FULL即binlog事件中记录完整的前镜像和后镜像这样才能拿到完整的数据行来执行DML。如果你的库用的是STATEMENT格式gh-ost会直接拒绝工作。2.2 从演练到正式的隐私流程gh-ost在正式执行前有一个非常实用的test模式相当于变更前的演习。在这个模式下它会正常解析binlog、正常创建影子表、正常复制历史数据但不会执行最后的切换和删表动作。跑一遍test模式你可以清楚地知道binlog链路通不通、主从延迟有多少、复制到影子表的进度如何、磁盘IO压力多大、整体耗时多久。确认一切正常后再真刀真枪地跑正式变更这个习惯我建议每个人都养成。正式变更最后一步是cut-over切换也就是把影子表和原表交换名字。gh-ost最典型、也最安全的做法基于原子重命名当历史数据和增量日志全部追平后它会执行两个相互关联的RENAME操作把原表改成_yourtable_del把影子表改成原表名。在MySQL的RENAME TABLE语法下这个操作是原子的瞬间完成对业务而言几乎是透明的。切换完成后gh-ost再异步清理掉那张_yourtable_del后缀的旧表。2.3 这个设计能避免哪些坑gh-ost的设计之所以被很多人接受我觉得主要赢在三点第一不需要触发器避免了pt-osc在主库上额外写入的开销也避免了触发器冲突问题。对于已经有触发器或者禁止创建触发器的环境这几乎是唯一的选择。第二操作可控。变更过程中可以随时--pause暂停、--throttle限速、甚至--panic退出。数据复制太快导致主从延迟时可以动态调低速度而不是像原生DDL一样闷头跑到底。第三对主库的压力更小。历史数据复制是在主库执行的所以IO压力还是会有但增量部分可以通过binlog分发到从库上处理某些场景还能把复制流量放到从库上降低主库负载。不过也别把gh-ost想成万能药它有几个硬性前提比如binlog必须是ROW格式表必须有主键或者唯一键以便定位行表没法有外键约束旧的MySQL版本支持不友好以及所有表操作必须通过gh-ost自己的入口。这些限制后面实操部分我会详细展开这里先有个概念就行。3. 动手之前先搞定这些前提条件gh-ost的启动参数很多但真正决定成败的不是参数而是前置环境。我见过有同事直接拿生产库跑结果因为binlog设置不对gh-ost一启动就报错退出。也有因为权限不足连创建影子表都没法执行。这里把关键的前提条件梳理一遍照着核查能省掉一堆麻烦。3.1 内核版本、binlog格式和权限准备先说版本。gh-ost官网给出的支持范围是MySQL 5.5、5.6、5.7、8.0以及Percona Server、MariaDB的部分版本。实际操作中我最常跑的是5.7和8.0基本都没问题。但需要注意MySQL 8.0的binlog格式默认已经是ROW这对gh-ost非常友好但8.0里如果表用了不可见索引或者某些新特性gh-ost未必认识需要提前做test模式验证。binlog相关设置最关键的是binlog_formatROW。可以用下面这句确认SHOW VARIABLES LIKE binlog_format;如果结果是ROWOK如果是STATEMENT或者MIXED需要先改配置并确认没有写入风险才调整。改binlog格式不是改一个参数那么简单它会影响所有基于statement的复制结构所以最好在变更窗口前完成。另外建议把binlog_row_image保持默认的FULL这样gh-ost拿到的每一行DML都有完整的前后镜像处理起来最快。如果库上为了节省带宽设置成了MINIMALgh-ost也能工作但对某些更新类型的处理会走更多查询性能差一些。权限方面gh-ost需要的最小权限是GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, UPDATE ON *.* TO ghost_user%;注意这里授权范围我给的是*.*因为在切换过程中需要执行RENAME操作涉及跨库元数据修改权限太窄会报错。除此之外它还需要具备SUPER权限用于在日志中识别自己的会话以及在某些情况下修改会话变量。生产环境如果对SUPER敏感可以尝试用--assume-rbr和部分参数绕开一部分限制但说实话给DBA专用账号开SUPER在业内很常见不必太教条。3.2 安装gh-ost与启动参数速查gh-ost是单二进制文件安装方式非常朴素从GitHub Releases页面下载对应平台的二进制包解压后放到/usr/local/bin加个执行权限就行。如果服务器能联网用wget直接拉最新版即可。也可以自己用源码编译但没必要官方release的版本就足够稳定。参数方面我挑几个大家最常用的列出来这些是跑一次变更基本都会用到的参数作用备注--host主库地址用主库ip--port主库端口默认3306--user数据库账号需要前文提到的权限--password数据库密码也支持从文件读取--database目标数据库名必填--table目标表名必填--alter变更语句不需要写ALTER TABLE直接写变更部分--execute真正执行不加就是演练模式--test-on-replica在从库演练用于测试切换--max-load最大负载阈值超过阈值自动限速--critical-load临界负载阈值超过直接终止--chunk-size历史数据批量复制行数默认1000--throttle-control-replicas监控哪些从库延迟默认监控所有--panic-flag-file熔断标志文件手动熔断--initially-drop-ghost-table启动前清理影子表推荐加上--initially-drop-old-table启动前清理旧表残留推荐加上--cut-over-lock-timeout切换锁超时默认3秒--approve-renamed-columns容忍列改名按需使用不要看着多就慌真正跑一次变更完整命令行大概是下面这个样子。我用的是先演练后执行的顺序。3.3 逃生窗口心跳和日志gh-ost还支持在变更过程中每隔几秒往MySQL里写一条心跳记录默认会创建一个_yourtable_ghc的日志表可以用来观察进度。生产上建议用--heartbeat-interval1这样的配置这样从日志表就能看到同步进度是否真的在往前走停了就知道出问题了。另外所有gh-ost操作都会打印日志到标准输出也可以指定--log-file把日志写入文件。我习惯同时开着屏幕输出和日志文件变更过程中一边看一边留档后面排查问题很有帮助。4. 从演练到实战完整跑一次变更光讲参数太干我拿一个近期真实遇到过的场景出来某订单明细表大概有4000万行单表约180G。业务需要在order_no字段上加一个索引加快按订单号查询的速度。按照以往经验原生ALTER TABLE在这个量级上至少要跑五十分钟到一小时而且期间写入压不压得住全看运气。我们决定用gh-ost来做。4.1 第一步连通性测试与库上状态检查在进行任何变更之前先检查目标库的状态这一步不能省。-- 查看主从复制是否健康 SHOW SLAVE STATUS\G; -- 查看当前有没有长时间运行的大事务或大查询 SELECT * FROM information_schema.processlist WHERE time 300 ORDER BY time DESC; -- 确认binlog格式 SHOW VARIABLES LIKE binlog_format;确认无误后先跑一次gh-ost的帮助命令确认版本没问题gh-ost --version我习惯先跑一次test模式它不动真实数据只验证链路和资源。在目标目录里准备好一个变更配置脚本或者直接命令行带上参数执行类似下面这样的命令gh-ost \ --host192.168.1.20 \ --port3306 \ --userghost_user \ --passwordyour_password \ --databaseshop \ --tablet_order_detail \ --alterADD INDEX idx_order_no(order_no) \ --chunk-size1000 \ --max-loadThreads_running50 \ --critical-loadThreads_running100 \ --initially-drop-ghost-table \ --initially-drop-old-table \ --heartbeat-interval1 \ --verbose \ --execute注意我故意在前面这个命令里加了--execute这说明是正式执行。演练模式要在命令前把--execute去掉或者用--test-on-replica在从库上跑并且通常会额外加一个--dry-run参数跑完直接退出只打印将要执行的动作不落地。4.2 正式变更开始过程实录正式执行时屏幕上会不断滚动进度日志。能看到类似这样的输出INFO: Migrating shop.t_order_detail to shop._t_order_detail_gho INFO: binlog format is ROW INFO: Chunk size: 1000 INFO: --max-load: Threads_running50 INFO: Estimated rows in shop.t_order_detail: 40000000 INFO: Copy progress: 12.5%, 5000000 rows, 28s elapsed INFO: Copy progress: 25.3%, 10120000 rows, 56s elapsed看到这种滚动说明历史数据复制正在按预期进行。这里有几个细节第一Estimated rows来自EXPLAIN SELECT的估算值不精确但它会动态修正。如果你表数据量特别大看到百分比长时间卡住不动别慌先看看是不是主从延迟触发了自动限速。第二chunk-size参数控制了每一批复制多少行。在IO紧张的环境里把它调小比如500或更小对主库的冲击会小很多。但也不是越小越好太小会导致网络往返次数增多整体效率降低。我一般默认1000起然后根据延迟情况动态调。第三在正式执行的过程中日志会周期性输出Copy progress以及throttle状态。一旦检测到主从延迟超过阈值屏幕上会出现类似INFO: throttle detected, sleeping 100ms这时相当于工具有效地把速度压了下来保护从库不被拖垮。变更中我习惯开两个终端一个看gh-ost日志另一个每隔几分钟看一次从库延迟SHOW SLAVE STATUS\G;观察Seconds_Behind_Master如果这个值持续上涨就需要评估是不是要手动限速或者暂停一下。4.3 切换瞬间和收尾检查gh-ost的切换在整个流程的最后段落下。日志会出现类似下面的内容INFO: All binary logs applied, switching to cut-over INFO: Locking shop.t_order_detail INFO: Renaming shop.t_order_detail to shop._t_order_detail_del INFO: Renaming shop._t_order_detail_gho to shop.t_order_detail INFO: Unlocking shop.t_order_detail INFO: Dropping old table shop._t_order_detail_del这个瞬间很快。只要业务是持续写入的状态切换期间会有一个非常短暂的锁写窗口默认超时是3秒。如果3秒内拿不到切换锁说明还有长事务占着表gh-ost会直接放弃本次切换进入一个后撤状态整体变更并不会把表搞坏只是需要你重新触发切换。切换完成后记得把旧表_t_order_detail_del删掉。gh-ost默认会自己删但删大表本身是一个很重的IO操作建议确认它在后台做了。如果因为异常没删干净也可以手动处理。末尾还要做几件收尾工作验证新表结构和索引是否真的生效。跑几条典型查询确认SQL能命中新索引。检查主从延迟已经恢复到正常水平。清理可能留下的日志表_t_order_detail_ghc没用了就删掉。SHOW INDEX FROM t_order_detail;5. 限速、暂停与熔断控制风险的核心手段5.1 自动限速和手动限速大表变更最怕的不是慢而是变更期间把库压垮。gh-ost提供了两套限速机制max-load和throttle-control-replicas。max-load设置一个MySQL状态变量的阈值比如Threads_running50意思是当活跃线程数超过50时触发限速。每次进入限速状态gh-ost会暂停一小段时间然后重新检测。critical-load更激进一旦达到临界值工具直接终止保护数据库不被拖死。我经常用的组合是--max-loadthreads_running50 \ --critical-loadthreads_running100 \ --throttle-control-replicas192.168.1.21:3306,192.168.1.22:3306throttle-control-replicas指定监控哪些从库的复制延迟。当这些从库的Seconds_Behind_Master超过设定值时触发限速。默认情况下gh-ost监控所有发现的从库这在大规模从库环境里可能过于敏感手动指定关键从库在实践中更合理。还有更灵活的手动限速方式gh-ost支持通过Unix socket发送指令比如echo throttle | nc -U /tmp/gh-ost.sock echo no-throttle | nc -U /tmp/gh-ost.sock echo pause | nc -U /tmp/gh-ost.sock echo resume | nc -U /tmp/gh-ost.sock echo panic | nc -U /tmp/gh-ost.sock这个功能真的非常有用。比如变更期间发现报警数据库IO飙升你不需要杀掉进程直接发个throttle变更立刻放慢速度等业务高峰过了再no-throttle恢复。这比我用过的任何其他在线DDL方案都更像是给数据库装了一个流量阀。socket文件的路径默认是在执行目录下创建也可以手动指定比如--socket/tmp/gh-ost.sock。5.2 变更过程中踩过的坑说实话刚开始用gh-ost时我没少踩坑挑几个典型的说说。第一个是binlog格式的问题。有个MySQL 5.6实例当时为了保证别的主从同步逻辑binlog_format是STATEMENTgh-ost一启动就报Row-based replication is required最后只能协调窗口期切换格式才跑完变更。后来我养成了习惯项目开始前先检查所有相关实例的binlog格式别指望gh-ost自己在运行时帮你改。第二个是表没有主键的问题。gh-ost必须通过主键或唯一键来定位数据行。只要表上既没有主键也没有唯一键它会直接拒绝执行。有的老业务表确实没建主键这时候得先补主键或者借助工具生成唯一键这是前置工作没法跳过。第三个是切换无法完成。某次变更跑到100%后日志显示cut-over一直不成功排查发现表上有长期的SELECT ... FOR UPDATE事务没提交导致RENAME操作拿不到MDL锁。我遇到这种情况的处理方式是先杀掉那批持锁事务然后重新触发切换。如果杀事务还不行就得等业务空闲窗口再切。第四个坑比较隐蔽用gh-ost变更表的同时业务进程里恰好有通过旧表结构写入的大量预处理语句切换瞬间会偶发报错。这是因为切换的瞬间表结构变了但某些连接缓存的是旧表结构信息。运维层面可以在变更前与开发团队确认一下是否有这类长连接或连接池缓存。如果确实有可以考虑在变更前的低峰期重启一次应用程序连接池清理掉旧结构缓存。5.3 最坏情况如何panic回滚虽然gh-ost设计得再稳也得考虑最坏情况。如果变更过程中发现严重问题比如主从延迟失控、IO打满或者业务异常不要犹豫立即执行echo panic | nc -U /tmp/gh-ost.sockpanic会让gh-ost立刻停止所有工作并退出。注意它不会自动帮你清理影子表但会留下_yourtable_gho和_yourtable_ghc两个表。在原表没有被动过、binlog追踪也正确的前提下原表数据是安全的业务完全无感。等排查完毕手动删除这两个残留表即可。执行panic之后建议顺手把影子表删掉避免它占用磁盘空间DROP TABLE IF EXISTS shop._t_order_detail_gho; DROP TABLE IF EXISTS shop._t_order_detail_ghc;这个操作在低峰期做因为删大表也是资源消耗大户。gh-ost本身也提供了--initially-drop-ghost-table这样的参数保证启动前清理掉上次残留的影子表我建议每次都加上防止上一轮的残留表对新的变更造成干扰。6. 常见问题与排查思路速查这块我直接整理成表格方便以后翻看。按优先级从高到低排列现象可能原因解决办法启动报Row-based replication is requiredbinlog_format不是ROW修改配置并重启或换支持ROW的实例。启动报No primary key found目标表无主键或唯一键先补主键/唯一键再执行gh-ost。启动报Could not connect to MySQL防火墙、账号权限或者网络不通检查端口、账号授权、网络连通性。启动报Unknown system variable tokudb_...Percona/分支版本兼容问题换个版本gh-ost或者去掉该分支特有的系统变量监听。进度长时间停在某个百分比触发限速或主从延迟高查看日志确认throttle状态必要时手动no-throttle同时检查从库压力。日志提示cut-over失败存在长事务或MDL锁冲突杀掉持锁事务调整--cut-over-lock-timeout稍大些错峰重试切换。变更过程中主库IO暴涨chunk-size太大或max-load设置过松降低chunk-size、调低max-load阈值、触发throttle。切换后查询走不到新索引统计信息没更新或者SQL写法问题执行ANALYZE TABLE刷新统计信息EXPLAIN验证执行计划。残留影子表占空间变更未正常结束手动DROP残留表或开启--initially-drop-ghost-table。MySQL 8.0报check constraint不支持表里有8.0新特性检查表的DDL定义去掉gh-ost不认识的新特性或用gh-ost新版。上面有些问题的细节我再补充几句。cut-over失败在实际中遇到频率不算低。尤其表上有长事务或大量SELECT ... FOR UPDATE时RENAME操作等待MDL锁的时间一超过--cut-over-lock-timeout就会失败。这时gh-ost不会退出而是保留在切换前状态原表照常工作影子表数据也照常追平。你可以等业务低峰或者杀掉卡顿事务后通过socket发resume让它再次尝试切表。关于主从延迟这里有一个经验值分享如果throttle-control-replicas指定的从库出现了明显延迟gh-ost会自动限速此时不要强行no-throttle不然很容易把延迟滚成雪球。建议等延迟降下来之后再手动恢复。这种自动限速手动确认的搭配最稳。还有一点特别值得提gh-ost的--alter语句不要写ALTER TABLE开头的完整SQL直接写ADD INDEX idx_order_no(order_no)这种变更子句就好。写多了它会报语法错误。MySQL 8.0上使用gh-ost有一点额外注意事项8.0默认开启binary log中的table_map事件加密或者部分特性gh-ost新版本已经兼容但老版本可能解析不了。如果遇到解析问题升级gh-ost版本往往就解决了。7. 其他没展开但值得知道的高级用法gh-ost并不只是纯DBA的工具开发手里有变更权限时也能直接拿来用。除了基础变更它还能做不少进阶操作简单提几个。一个是变更过程中在从库上做test-on-replica。这相当于先在从库上完整模拟一次表结构变更包括最终的切表动作。好处是它不动主库的生产流量却能把整个流程、耗时、资源开销都测一遍输出结果和正式变更几乎一致。很多团队把这一步当作发布流程里的必选环节。一个是--alter语句支持一次带多个变更操作比如同时加两个索引、改一个字段默认值ADD INDEX idx_order_no(order_no), ADD INDEX idx_user_id(user_id), MODIFY COLUMN status INT DEFAULT 0这样能减少切换次数对长期有DDL需求的业务非常友好。还一个是配合定时任务跑定期清理或归档流程如果业务需要定期删除老数据、重建分区表在核心库上用gh-ost可以避免删除大表过程中的锁和磁盘压力。当然gh-ost更偏结构变更和专门的归档工具分工不同但在没有专用工具时拿它兜底也是可行的。gh-ost的socket交互接口也支持通过HTTP方式封装成内部运维平台的能力不少公司会把它集成到自己的数据库变更工单系统里实现提交工单-自动预检-低峰期自动执行-结果回写的全链路比人肉敲命令规范得多。如果你所在的团队变更频繁强烈建议把gh-ost用起来的同时把常用的变更命令固化成脚本统一参数风格和命名规范减少人工操作中的意外。8. 我自己踩过坑后总结的几条建议从第一次用gh-ost到现在前前后后也有五六年了简单总结几条个人经验。第一变更前的预检一定要做细。binlog格式、主键、外键、磁盘空间、从库延迟哪一项出问题都会中途翻车与其到变更中途去救火不如在开始前多花十五分钟检查一遍。第二首次使用一定先从test模式开始。哪怕你觉得自己已经理解得很透了也建议先在从库或者备用环境上模拟一次。这个动作成本很低但能过滤掉大量低级问题。第三正式执行时开着日志人在旁边盯着别甩完命令就去做别的。gh-ost虽然可控但中途可能因为各种外部因素需要人工介入。盯场的人不一定需要做什么但至少得知道在哪里做。第四宁可慢一点也不要把限速阈值设置得太高。我见过有人在1000并发写入的库上跑变更max-load设置成500结果变更时间长了点但主库状态很稳。反而是那些追求速度、把阈值调得很高的人最后往往被迫中途踩刹车。第五变更完成之后不要马上放松警惕。切表完成后t1到t2小时依然要观察主从延迟、慢查询和异常报错。偶尔会有因统计信息没更新导致执行计划走偏的情况需要手动ANALYZE TABLE或者和开发一起改SQL。gh-ost本身已经是一个非常成熟的开源工具GitHub上这个项目后来转入维护状态社区维护节奏放缓但这并不影响它在业界的广泛使用。我至今仍把gh-ost当作核心库表结构变更的第一选择。如果你还没试过可以从一个小表开始先跑test模式感受一下过程再慢慢推到大表上。整体上手成本并不高但带来的安全感和可控性绝对值得投入这点学习时间。最后再分享一个小细节gh-ost执行前会在日志里打印一条Will use socket at: /tmp/gh-ost.sock那个socket其实是个交互入口。没事儿的时候连上去敲个status看看你会对工具的运行状态有更直观的理解以后排查问题也更自信。