1. 问题背景MySQL主从同步为何突然中断上周三凌晨2点15分生产环境的MySQL从库突然报警显示主从同步延迟超过300秒。作为DBA值班人员我立即登录服务器检查状态。当时show slave status显示Slave_IO_RunningYes但Slave_SQL_RunningNo错误信息提示Could not execute Write_rows event on table db.order; Duplicate entry 178293 for key PRIMARY。这种情况在电商大促期间并不罕见但这次异常发生在业务低峰期且主库没有明显的批量操作。更奇怪的是这个主键冲突的记录在主库根本不存在这让我意识到问题可能比表面看起来更复杂。2. 排查路线图从表象到根源的六步分析法2.1 第一步验证基础同步状态首先确认基本同步参数是否正常SHOW VARIABLES LIKE server_id; SHOW VARIABLES LIKE log_bin; SHOW VARIABLES LIKE binlog_format;发现从库的server_id居然与主库相同这是第一个严重配置错误。虽然这不会直接导致主键冲突但会导致网络分区时出现脑裂风险。立即用SET GLOBAL临时修改并在my.cnf中永久修正。2.2 第二步解析冲突的relay log通过mysqlbinlog工具分析出问题的relay logmysqlbinlog --base64-outputdecode-rows -v /var/lib/mysql/relay-log.000123在position 471238位置发现了可疑的INSERT语句。该语句试图插入主键为178293的记录但主库binlog中根本没有对应记录。这说明有幽灵事件混入了同步流。2.3 第三步GTID一致性校验启用GTID跟踪后发现更诡异的现象SHOW GLOBAL VARIABLES LIKE gtid_mode; SELECT * FROM mysql.gtid_executed;从库的gtid_executed表中存在一组不属于主库任何binlog的GTID例如a1b2c3d4-5e6f-7890-1234-567890abcdef:10000-15000。这些凭空出现的事务正是导致冲突的元凶。3. 深度分析relay log污染的三重可能3.1 可能性一人为误操作检查操作日志发现有开发人员曾执行过STOP SLAVE; SET GLOBAL sql_slave_skip_counter10; START SLAVE;这种暴力跳过错误的方式会破坏GTID连续性。更糟的是该开发人员随后手动执行了数据修复脚本这些操作被误记入从库的binloglog_slave_updatesON形成污染源。3.2 可能性二网络分区导致的事件重复在故障时间点监控显示网络有3次30秒左右的闪断。MySQL 5.7的自动重连机制可能导致部分事件被重复传输。通过比对主从binlog的checksum值确认了重复事件的存在。3.3 可能性三备份恢复的副作用排查发现一周前做过从库的物理备份恢复。当时使用xtrabackup重建时未正确清理原有的relay log文件导致旧事件与新事件混合。这解释了那些幽灵GTID的来源。4. 修复方案五步完整恢复流程4.1 第一步建立数据基准点在主库锁定相关表后执行FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;记录下File和Position值同时在从库用mysqldump导出冲突表的结构和数据形成恢复基准。4.2 第二步彻底重置复制环境在从库执行完整清理STOP SLAVE; RESET SLAVE ALL; RESET MASTER; PURGE BINARY LOGS BEFORE NOW();删除所有relay log文件rm -f /var/lib/mysql/relay-log.*4.3 第三步重建复制链路使用正确的GTID自动定位方式重建复制CHANGE MASTER TO MASTER_HOSTmaster_host, MASTER_USERrepl_user, MASTER_PASSWORDpassword, MASTER_AUTO_POSITION1;4.4 第四步数据一致性校验使用pt-table-checksum进行全量校验pt-table-checksum --replicatetest.checksums hmaster_host,ucheck_user pt-table-sync --replicate test.checksums hmaster_host,usync_user --print对差异数据生成修复脚本经审核后执行。4.5 第五步防护措施加固修改配置防止问题复发[mysqld] slave_parallel_workers4 slave_parallel_typeLOGICAL_CLOCK sync_relay_log1 sync_relay_log_info1 slave_preserve_commit_order15. 经验总结主从同步的七个必知必会GTID使用铁律任何情况下都不要手动设置sql_slave_skip_counter应该通过注入空事务处理冲突备份恢复规范使用xtrabackup重建从库时必须添加--slave-info参数并清理旧relay log网络隔离防护配置master_retry_count和master_connect_retry控制重试行为监控关键指标除了Seconds_Behind_Master还要关注Exec_Master_Log_Pos的推进情况权限最小化回收开发人员的STOP SLAVE权限通过中间件控制日志保留策略主库binlog保留7天以上从库relay log至少保留3天定期校验机制每周用pt-table-checksum做全量校验关键业务表每天校验这次事故的根本原因在于多重防护措施被绕过。事后我们建立了复制环境变更的checklist任何涉及复制的操作都需要双人复核。同时优化了监控系统当检测到server_id冲突、GTID断层等异常情况时会自动触发告警并锁定复制账户。关键教训主从同步不是配置完就忘的服务需要像对待数据库核心服务一样进行日常监控和维护。每次异常处理都应该形成闭环把临时解决方案转化为长期防护机制。