主从复制冲突因数据不一致导致，需谨慎处理。先通过SHOW SLAVE STATUS识别错误类型，如主键冲突或记录不存在；应急时可跳过单个错误事件，但有风险；建议启用GTID模式减少重复事务冲突；数据差异大时应使用mysqldump或XtraBackup重新同步；预防上禁止写从库、监控延迟与一致性，定期校验数据。
MySQL主从复制出现冲突时，通常是因为主库和从库的数据不一致，导致从库在重放二进制日志（binlog）时执行失败。处理这类问题需要谨慎，既要保证数据一致性，又要尽量减少服务中断。以下是常见的处理方式和建议。
1. 识别复制冲突类型
常见的复制冲突包括：
- 主键冲突：从库插入已存在的主键或唯一键。
- 记录不存在：从库执行UPDATE或DELETE时找不到对应行。
- SQL线程报错：通过SHOW SLAVE STATUS\G查看Last_SQL_Error字段可定位具体错误。
例如错误信息可能显示“Duplicate entry 'xxx' for key 'PRIMARY'”，说明发生了主键重复。
2. 短期应急处理：跳过错误
在非关键业务或明确知道不影响数据完整性的场景下，可以临时跳过错误。
- 跳过一个错误事件：
STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE; - 适用于偶发性、可忽略的错误，如临时表操作或测试数据写入。
注意：此方法风险较高，可能导致主从数据进一步不一致，仅建议用于紧急恢复。
3. 使用GTID复制避免部分冲突
启用GTID（全局事务标识）后，每个事务都有唯一ID，从库会自动忽略已执行的事务，减少重复执行导致的冲突。
- 配置主从使用GTID模式：
gtid_mode=ON
enforce_gtid_consistency=ON - 遇到冲突时可通过@@GLOBAL.gtid_executed对比主从事务集，精准修复。
4. 数据修复与重新同步
当冲突频繁或数据差异大时，应重新同步从库。
- 使用mysqldump导出主库数据并导入从库：
mysqldump --master-data --single-transaction db_name > backup.sql - 或使用Percona XtraBackup进行物理热备，效率更高。
- 恢复后确保从库的CHANGE MASTER TO指向正确的binlog位置或GTID点。
5. 预防措施
避免冲突的根本在于规范操作和架构设计。
- 禁止对从库进行写操作，防止数据漂移。
- 主库变更表结构前，确认从库兼容性。
- 监控复制延迟和错误，及时告警。
- 定期校验主从数据一致性，可使用pt-table-checksum工具。
基本上就这些。关键是根据实际场景选择跳过、修复还是重建，同时建立预防机制减少问题发生。
