MySQL主从架构下数据库在线变更实现方法

先说一个核心判断：在MySQL主从复制架构中执行在线DDL变更，真正的难点并非主库，而是从库。直接在主库运行一条 ALTER TABLE，主库可能只需几秒完成，但从库却可能卡顿数十分钟，甚至引发复制中断。许多DBA和开发人员只有在线上遇到故障后，才深刻意识到从库延迟的严重性。

主从环境下的在线架构变更，本质目标只有一个：确保变更在主库生效的同时，不破坏从库的同步链路，避免数据不一致。这并非“能否执行”的问题，而是“如何安全执行”的核心挑战。

主库执行 Online DDL 时，从库为什么会出问题？

MySQL 的 Online DDL 在主库上看似无锁，但问题出在它的 binlog 记录方式。从库真正重放的不是你想象的“原地无锁操作”，而是 binlog 里写好的那个版本。

• 例如，ADD COLUMN 操作在 MySQL 5.6 及以上版本支持 ALGORITHM=INPLACE，但 binlog 中仍可能以 ALTER TABLE ... ALGORITHM=COPY 形式记录——特别是当 server_id 不匹配或未显式指定参数时。这导致从库被迫重建表、锁定表，从而引发延迟飙升。
• 修改列的默认值（ALTER COLUMN ... SET DEFAULT）直到 MySQL 8.0.23 之后才实现真正无锁。在旧版本中，即使主库不锁表，从库的 SQL 线程执行时仍会获取元数据锁（MDL），从而阻塞其他查询。
• 如果主库启用了 binlog_row_image=MINIMAL，部分 DDL 的 row event 可能缺失关键字段，进而触发从库的 Last_SQL_Errno: 1785（事务依赖冲突）。

pt-online-schema-change 在主从环境下必须加的三个参数

使用 pt-online-schema-change 显然更稳妥，但一个容易被忽略的事实是：该工具默认只操作主库，对从库完全没有感知。不添加约束就跑，主从结构不一致的故障几乎是必然的。

• --recursion-method=none：禁止自动探测从库，防止工具误判拓扑结构而连接错误节点。
• --check-slave-lag=h=slave_host,u=user,p=pass,P=3306：显式指定一个从库，持续监控 Seconds_Behind_Master 指标。一旦延迟超过 30 秒，工具自动暂停复制操作，避免从库追赶不上主库的写入节奏。
• --slave-user 和 --slave-password：确保工具能够在从库上执行 SELECT COUNT(*) 校验。如果遗漏这两个参数，校验步骤会被直接跳过，导致数据一致性失去保障。

这三个参数缺一不可，漏掉任何一个都可能导致“主库变更完成，从库仍在同步旧结构”的静默故障。更严重的是，这种故障往往难以察觉，直到引发数据不一致时才被发现。

GTID 模式下变更前必须验证的两个点

开启 GTID 之后，DDL 的原子性和可追溯性确实提升了不少，但代价是校验逻辑变得更严格。变更前有两件事必须确认：

• 在运行 pt-online-schema-change 之前，先在主库执行 SELECT @@global.gtid_executed; 记录当前 GTID 集合。变更完成后，再到从库执行同样的查询，确认两个 GTID 集合完全一致——注意，不是“包含”，而是必须相等。
• 变更过程中严禁执行 SET GLOBAL sql_log_bin = 0。GTID 机制要求所有变更都必须写入 binlog，绕过日志会使得从库无法识别事务边界，后续的 WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS 命令也会完全失效。

切换后最容易被忽略的索引同步问题

很多团队把注意力全放在表结构上，忽略了索引在主从之间并不是“自动镜像”的。几个常见的坑：

• 在主库使用 ALGORITHM=INPLACE, LOCK=NONE 添加二级索引时，但从库可能因磁盘 I/O 压力过大，SQL 线程在重放该 DDL 时降级为 COPY 模式，耗时数分钟。此时 SHOW PROCESSLIST 显示 altering table，但应用层完全无法感知这一差异。
• 如果从库将 innodb_adaptive_hash_index 设为 OFF，而主库为 ON，相同的 DDL 在从库上执行得更慢，延迟自然逐渐累积。
• 变更完成后立即在从库执行 SHOW INDEX FROM tbl_name，可能发现新索引存在但 Cardinality 值为 0——这表示统计信息尚未更新，需要手动执行 ANALYZE TABLE，否则查询计划可能退化。

因此，一次完整的在线架构变更并非以主库返回 success 为终点。必须等到从库的 Slave_SQL_Running_State 恢复为 Waiting for next chunk，并且 Seconds_Behind_Master 稳定归零至少 60 秒，才能真正确认变更已安全落地。