mysql如何实现主从架构下的DDL变更_使用Ghost工具避免同步延迟-mysql教程-PHP中文网

mysql主从架构下直接执行ddl会导致同步延迟，因为大表ddl持有mdl锁阻塞读写，且row格式binlog中ddl仍以statement方式记录，从库无法并行回放；gh-ost通过影子表+binlog增量同步实现无锁变更，仅产生轻量dml和一次rename，避免锁表与复制阻塞。

mysql如何实现主从架构下的ddl变更_使用ghost工具避免同步延迟

MySQL主从架构下直接执行DDL为什么会导致同步延迟

因为 ALTER TABLE 在主库上执行时，会以「语句级」或「行级」方式写入 binlog，而大表 DDL 会持有元数据锁（MDL），阻塞后续读写；从库回放时若表数据量大、IO 或 CPU 资源不足，就会卡在 altering table 状态，导致 Seconds_Behind_Master 持续上涨，甚至堆积 relay log。

更麻烦的是：5.7+ 默认 binlog_format=ROW，但 DDL 仍以 statement 形式记录（即使开了 binlog_row_image=FULL 也无效），从库必须等整个 DDL 执行完才继续，无法并行回放。

为什么 Ghost（gh-ost）能绕过同步延迟问题

gh-ost 不依赖 MySQL 原生 DDL，而是用「影子表 + 增量日志解析」方式实现无锁变更：它在主库上创建新表结构，通过监听 binlog 捕获原表的增删改操作，并实时同步到影子表；待全量拷贝完成、增量追平后，用原子 RENAME 切换表名——整个过程不阻塞主库写入，从库只看到轻量的 INSERT/UPDATE/DELETE 和最终一次 RENAME，几乎不影响复制延迟。

关键点：

gh-ost 默认连接主库执行，但所有写操作都走主库，从库仅被动回放，因此不会加剧从库压力
它不使用触发器（对比 pt-online-schema-change），规避了触发器在 GTID 模式下的兼容性问题
支持 --allow-on-master 强制在主库运行，也支持 --assume-rbr 明确告知已开启 ROW 格式
通过 --max-load 和 --critical-load 控制对主库负载的影响，避免因拷贝拖慢线上业务

gh-ost 实际执行时必须注意的参数和条件

不是加几个参数就能跑起来，漏掉关键约束会失败或引发主从不一致：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

主库必须开启 binlog_row_image=FULL（MySQL 5.6.22+），否则无法捕获完整变更字段
用户需有 SELECT、INSERT、UPDATE、DELETE、DROP、CREATE 权限，且能访问 information_schema
必须指定唯一可排序索引（如主键或带 NOT NULL 的唯一索引），gh-ost 靠它分块读取原表，否则报错 Cannot find a unique key
避免在从库上执行 —— gh-ost 不支持 --host 指向从库，它需要直连主库解析 binlog
DDL 语句要写进 --alter 参数里，例如：--alter="ADD COLUMN status TINYINT DEFAULT 0"，不能带 ALTER TABLE t1

典型命令示例：

gh-ost \
--user="root" \
--password="xxx" \
--host="master-host" \
--database="mydb" \
--table="orders" \
--alter="ADD COLUMN updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP" \
--assume-rbr \
--allow-on-master \
--cut-over-exponential-backoff \
--chunk-size=1000 \
--max-load="Threads_running=25" \
--critical-load="Threads_running=50" \
--initially-drop-ghost-table \
--initially-drop-old-table \
--execute