答案：MySQL复制冲突常见于主从或主主结构中，主要类型包括主键冲突、记录不存在、表结构不一致和事务重复执行。可通过SHOW SLAVE STATUS命令检查Slave_IO_Running、Slave_SQL_Running、Last_Error等字段及时发现异常。处理方式有：跳过单个错误事件、配置自动忽略特定错误码、手动修复数据一致性或基于GTID注入空事务跳过错误。预防措施包括避免从库写入、保持配置一致、定期校验数据、启用read_only及使用读写分离中间件。建立监控机制是关键，确保问题早发现早处理。
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中设置忽略常见错误码：
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参数防止误写从库。
基本上就这些。关键是建立监控机制，早发现早处理，避免小问题演变成大故障。复制冲突不可怕，可怕的是没察觉。
