主从不同步需先检查Slave_IO_Running和Slave_SQL_Running状态，根据错误类型处理：主键冲突可跳过事务；表结构不一致需手动修复或使用pt-table-sync；binlog丢失则需重新备份恢复；GTID异常可通过注入空事务解决，并建议设置read_only、监控延迟、合理配置binlog保留时间及使用半同步复制预防问题。
MySQL主从不同步是数据库运维中常见问题，通常表现为从库（Slave）的延迟增加或复制中断。解决这类问题需要先定位原因，再采取相应措施。以下是常见的排查与修复方法。
检查主从同步状态
登录从库执行以下命令查看复制状态：
SHOW SLAVE STATUS\G
重点关注以下字段：
- Slave_IO_Running：是否正常拉取主库binlog
- Slave_SQL_Running：是否正常执行SQL
- Last_Error：最近的错误信息
- Seconds_Behind_Master：延迟秒数
如果其中一项为“No”，说明同步已中断。
常见问题及处理方式
根据错误类型选择对应解决方案：
1. 主键冲突或记录已存在
错误示例：Duplicate entry for key 'PRIMARY'
这种情况多出现在误操作或手动写入从库后。可跳过该事务：
SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;
;注意：仅适用于非关键数据，跳过前需确认影响范围。
2. 表不存在或DDL不一致
主库执行了建表或删表操作，但从库未同步或结构不一致。
解决方法：
- 在从库手动创建缺失表（确保结构一致）
- 使用
pt-table-sync工具校验并修复结构差异
3. 主库binlog被删除或找不到
错误提示：Could not find first log file name in binary log index
说明从库请求的binlog已被主库清理。
此时只能重新搭建从库：
- 对主库进行逻辑备份（mysqldump）或物理备份（xtrabackup）
- 恢复到从库
- 重新配置CHANGE MASTER TO指向当前主库binlog位置
4. GTID模式下同步异常
若启用GTID，出现“Fatal error on slave”时，可通过注入空事务修复：
STOP SLAVE; SET GTID_NEXT='指定缺失的GTID'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;
具体GTID值需根据错误日志确定。
预防主从不同步的建议
避免问题发生比修复更重要：
- 禁止直接在从库写入数据（设置read_only=ON）
- 定期监控Seconds_Behind_Master指标
- 合理设置主库binlog过期时间（expire_logs_days）
- 使用半同步复制（semi-sync）提升数据一致性
- 定期用pt-table-checksum校验主从数据一致性
基本上就这些。主从不同步虽然常见，但只要掌握基本排查流程，多数问题都能快速定位和恢复。关键是平时做好监控和维护，减少人为干预带来的风险。
