MySQL复制过程中，由于主从结构的异步或半同步机制，在某些场景下可能会出现数据不一致或复制冲突。这类问题常见于主主复制、故障切换后恢复、手动修改从库数据等情况。处理复制冲突的核心是及时发现、准确定位并合理解决，避免服务中断或数据丢失。
1. 常见的复制冲突类型
了解冲突类型有助于快速判断问题来源：
主键冲突（Duplicate entry）：在从库插入已存在的主键值，通常发生在主主复制中双写数据。 记录不存在（Can't find record）：执行DELETE或UPDATE时，从库找不到对应行。 表结构不一致：主库和从库表结构不同，导致SQL语句执行失败。 事务冲突：GTID模式下，事务已应用但再次尝试执行。2. 如何检测复制冲突
通过以下命令查看复制状态：
SHOW SLAVE STATUS\G重点关注以下字段：
Slave_IO_Running 和 Slave_SQL_Running：应为Yes。 Last_Errno 和 Last_Error：显示最近的错误代码和描述。 Seconds_Behind_Master：延迟时间，持续为NULL可能表示复制中断。3. 复制冲突的处理方法
根据错误类型选择合适的解决方案：
方法一：跳过单个错误事件
适用于临时性或可忽略的错误（如已知的重复插入）：
STOP SLAVE;SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;
注意：此方式仅跳过一个事件，需谨慎使用，避免数据进一步不一致。
方法二：配置自动跳过特定错误
在
my.cnf中设置忽略常见错误码： [mysqld]
slave-skip-errors = 1062,1032,1058
例如：1062为主键冲突，1032为记录不存在。生产环境慎用，建议仅用于测试或紧急恢复。
方法三：手动修复数据一致性
当冲突源于数据差异时，需手动校对并修正：
在从库查询缺失或冲突的数据行。 从主库导出正确数据并导入从库。 确认数据一致后重启复制。可借助工具如
pt-table-checksum和
pt-table-sync检测和修复差异。
方法四：基于GTID的复制修复
若启用GTID，可通过注入空事务跳过错误事务：
STOP SLAVE;SET GTID_NEXT='指定出错的GTID';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE;
该方法精准跳过已知GTID事务，适合高级运维操作。
4. 预防复制冲突的建议
减少冲突发生比事后处理更重要：
避免在从库执行写操作，尤其是主主复制架构。 保持主从版本和配置一致。 定期检查复制延迟和数据一致性。 使用读写分离中间件控制写入口。 开启read_only参数防止误写从库。
基本上就这些。关键是建立监控机制，早发现早处理，避免小问题演变成大故障。复制冲突不可怕，可怕的是没察觉。
