mysql从库执行DDL锁表怎么办_采用gh-ost或pt-osc工具同步

从库执行DDL更易锁表？先别急着动手，搞清原理再操作

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

从库执行 DDL 为什么比主库更容易锁表

这事儿得从MySQL的复制机制说起。尤其是在MySQL 5.7及更早的版本里，从库的SQL线程默认是“单线程回放”模式。什么意思呢？就是它得老老实实、一个接一个地串行执行relay log里的事件。

问题就出在这儿。一旦这个队列里混进了一个需要全表扫描或重建表的ALTER TABLE这类DDL，整个复制流水线就被它一个人给“卡”住了。后续所有的更新、插入语句，甭管多急，都得在后面排队等着它完工。主库上可能只是“唰”一下的瞬间操作，到了从库这里，就可能演变成持续几分钟甚至几小时的漫长等待。

怎么判断是不是卡住了？执行show processlist，如果看到SQL线程的状态显示为altering table，同时用show open tables where in_use > 0命令又能看到对应表被占用，那基本就是它了。

gh-ost 和 pt-osc 到底解决的是哪个环节

这两个大名鼎鼎的在线表结构变更工具，它们解决的可不是“已经卡死的锁”，而是“如何从一开始就不去制造锁”。它们的核心思路，是把原生的、一把锁锁全表的DDL操作，拆解成一个“无锁增量迁移”的精细活：先新建一张影子表，然后一点点地把数据同步过去，期间持续追平主库的变更，最后来个原子切换，完成变更。

关键在于——整个过程，主库的写入不受任何阻塞，从库的复制也完全不用停。听起来很美好，对吧？但这里有几个关键的细节必须拎清楚：

• 默认战场在主库：无论是gh-ost还是pt-online-schema-change，默认都是在主库上运行的。gh-ost通过监听主库的binlog来捕获变更；pt-osc也是类似。如果你非要在从库上跑，就得额外配置。比如gh-ost需要加上--recursion-method=none并手动指定--host，否则工具会自动探测拓扑并很可能报错。
• 从库执行的限制：gh-ost依赖BINLOG_FORMAT=ROW，并且如果要在从库场景下让它能读取到变更，从库必须开启log_sla ve_updates。而pt-osc在从库（只读）上执行时，创建触发器这步会失败，所以必须使用--no-drop-triggers和--no-swap-tables的组合，让它只做数据拷贝，最终的切换需要人工介入。
• 最重要的一点：它们都是“预防手段”，而不是“急救方案”。如果当前已经有一个DDL在从库上卡死了，这两个工具是束手无策的。

从库 DDL 卡死时，别急着 kill，先确认是否真能切走

遇到从库DDL卡住，很多人的第一反应就是去KILL掉那个线程。且慢！这个操作风险不小，贸然执行可能导致复制直接中断、relay log损坏，甚至出现Sla ve_SQL_Running: No的尴尬局面。

正确的处理姿势应该是这样的：

• 第一步，诊断：先执行SHOW SLA VE STATUS\G，重点观察Seconds_Behind_Master（复制延迟）是否在持续增长，以及Exec_Master_Log_Pos（已执行的日志位置）是否长时间停滞不前。
• 第二步，排查元凶：运行SELECT * FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 1;，看看是不是有未提交的长事务（比如一个忘了提交的UPDATE或DELETE）在背后阻塞了DDL。这种情况其实很常见。
• 第三步，谨慎操作：如果确认就是DDL自身因磁盘I/O瓶颈或内存不足等原因卡住了，并且业务上可以接受短暂的复制延迟，那么可以考虑先STOP SLA VE;暂停复制，然后再KILL掉那个在SHOW PROCESSLIST中显示为Command=Query且State=altering table的线程。
• 第四步，善后：在重启复制（START SLA VE;）之前，务必检查一下relay-log.info文件或GTID位置是否一致，避免不小心跳过了某些尚未执行的事件，造成数据不一致。

真正想在从库做 DDL 迁移？优先改用主库+工具+延迟从库策略

说实在的，在生产环境中，几乎找不到“必须专门在从库执行DDL”的强理由。一个更稳健、更通用的最佳实践是：将所有表结构变更，统一放在主库，使用gh-ost或pt-osc这类工具来执行，然后让从库自然地通过复制链路同步过去。

如果担心变更对主库性能有影响，可以配合一个“延迟从库”来玩。通过CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 3600（MySQL 8.0语法）设置一个比如一小时的延迟。这样，你可以先在主库完成变更，然后在这个延迟从库上观察验证，确认无误后，再考虑在其他从库上操作（此时风险已经充分暴露和可控）。

强行在从库上运行在线DDL工具，往往会因为权限、binlog格式设置、复制过滤规则等各种细节问题而“翻车”，得不偿失。

最后补充一个容易被忽略的参数：无论使用哪个工具，都要注意innodb_lock_wait_timeout这个值的设置。如果把它设得太小（比如只有5秒），而工具内部操作又需要等待锁，就可能导致工具频繁地因锁等待超时而失败、重试，反而拖慢了整个变更的进度。