主库执行Online DDL时从库会出问题，因其binlog记录方式导致从库被迫重建表、锁表或MDL阻塞；pt-osc需加--recursion-method=none、--check-slave-lag和--slave-user三参数保障主从一致；GTID模式下须校验gtid_executed完全相等且禁用sql_log_bin=0。
主从环境下的在线架构变更，本质是让变更在主库生效的同时，不破坏从库同步链路、不引发数据不一致。这不是“能不能做”的问题，而是“怎么做才不出错”的问题——直接在主库跑 ALTER TABLE 很可能让从库卡住甚至中断复制。
主库执行 Online DDL 时，从库为什么会出问题？
MySQL 的 Online DDL 在主库上看似无锁，但它的 binlog 记录方式决定了从库能否安全重放：
- 某些操作（如
ADD COLUMN）在 5.6+ 中支持ALGORITHM=INPLACE，但 binlog 里仍以ALTER TABLE ... ALGORITHM=COPY形式写入（尤其当 server_id 不匹配或参数未显式指定时），导致从库被迫重建表、锁表、延迟飙升 - 修改列默认值（
ALTER COLUMN ... SET DEFAULT）在 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 集合；变更完成后，在从库查SELECT @@global.gtid_executed;，确认两者完全一致（不是“包含”，而是“相等”） - 变更过程中禁止执行
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 秒。
