MySQL主从复制架构下，执行DDL操作是日常管理中的常见操作，但如果操作不当很容易引发主从同步停止的问题。本文记录一次实际生产环境中因DDL操作导致主从复制中断的问题排查与解决过程。
问题现象
运维人员在对主库的一张业务表执行添加字段的DDL操作后，发现从库的复制状态异常，查看从库复制状态显示Slave_SQL_Running值为No，复制已经停止。错误信息提示在执行主库传来的binlog事件时出现异常。
问题排查
首先查看从库的复制错误信息，执行以下命令获取详细错误内容：
SHOW SLAVE STATUSG
从返回的结果中可以看到Last_SQL_Error字段的报错信息，提示在执行DDL语句时，从库上对应的表结构与主库执行DDL时的上下文不匹配，导致DDL执行失败。进一步分析主库的binlog内容，确认主库执行的DDL语句为：
ALTER TABLE user_info ADD COLUMN age INT DEFAULT 0 COMMENT '用户年龄';
检查从库对应表的结构，发现该表之前已经被手动修改过字段顺序，与主库原始的表结构存在差异，导致主库传来的DDL语句在从库执行时无法正确匹配表结构，从而触发错误停止复制。
解决步骤
临时恢复复制
首先需要跳过当前出错的binlog事件，让复制继续运行。操作前先记录当前出错的binlog文件和位置，然后执行以下命令跳过错误：
STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;
执行后再次查看从库复制状态，确认Slave_SQL_Running恢复为Yes，复制暂时恢复正常。
同步表结构
跳过错误只是临时方案，需要保证从库表结构与主库一致。在主库执行以下命令获取最新的表结构：
SHOW CREATE TABLE user_info;
将返回的结果在从库执行，重新同步表结构，确保主从表结构完全一致。执行完成后再次检查从库复制状态，确认没有新的错误产生。
验证数据一致性
表结构同步完成后，需要验证主从数据的一致性，可以使用pt-table-checksum工具进行校验，或者在业务低峰期对比关键表的数据行数和核心字段内容，确保主从数据没有差异。
问题预防建议
- 执行DDL操作前，先确认主从表结构完全一致，避免表结构差异导致DDL执行失败。
- 对于大表的DDL操作，建议使用在线DDL工具，减少对业务的影响，同时降低主从复制异常的概率。
- 执行DDL操作前，先在测试环境模拟执行，确认操作不会引发主从复制问题后再在生产环境执行。
- 定期监控主从复制状态，设置复制异常告警，及时发现并处理复制停止的问题。
总结
DDL操作导致MySQL主从停止是比较常见的问题，核心原因通常是主从表结构不一致或者DDL执行时的上下文不匹配。遇到此类问题时，先通过SHOW SLAVE STATUS命令定位错误原因，再针对性地跳过错误、同步表结构、验证数据一致性，即可快速恢复复制。日常运维中做好预防措施，可以有效减少此类问题的发生。