主从冲突因数据不一致导致，需通过SHOW SLAVE STATUSG查看Last_Error定位问题；常见错误为主键冲突、记录不存在等；可临时用SET GLOBAL sql_slave_skip_counter=1跳过非关键错误；建议手动修复数据并用pt-table-checksum校验一致性；预防措施包括禁止从库写入、主库执行结构变更、使用row格式binlog及定期监控复制状态。
mysql主从复制出现冲突时，通常是因为主库和从库的数据不一致导致的。这类问题会影响数据同步，严重时会导致复制中断。处理主从冲突的关键是快速定位、合理修复，并防止再次发生。
检查冲突原因
当从库报错停止复制时，第一步是查看错误信息：
- 执行 SHOW SLAVE STATUSG，关注 Last_Error 或 Last_SQL_Errno 字段
- 常见错误包括：主键冲突（1062）、记录不存在（1032）、表结构不一致等
- 结合错误码和 SQL 线程状态判断是数据问题还是结构变更未同步
跳过单次冲突事件
对于偶发性、非关键性冲突，可临时跳过错误继续同步：
- 使用 SET GLOBAL sql_slave_skip_counter = 1 跳过当前错误事务
- 然后执行 START SLAVE; 恢复复制
- 注意：此方法适用于已确认该操作不影响业务逻辑的场景
手动修复数据一致性
如果跳过可能导致后续问题，应手动修正数据：
- 根据错误日志找到冲突的表和记录，比如主键重复插入
- 在从库上删除多余记录或补全缺失数据
- 例如：从库存在主键为100的行，而主库要插入同主键，可先删从库再重试
- 修改后建议用 pt-table-checksum 工具校验整体一致性
预防主从冲突的措施
避免冲突比处理更重要：
- 确保所有写操作只发生在主库，禁止对从库进行写入
- 结构变更（ALTER、DROP）需在主库执行并确认同步完成
- 使用 row 格式的 binlog 更安全，减少基于语句的不确定性
- 定期监控复制延迟和状态，及时发现潜在问题
基本上就这些。关键是保持主从环境干净统一，遇到冲突先查日志再决定跳过还是修复，事后做一次数据比对更稳妥。