MySQL复制冲突常见于主从或多主环境，主要类型包括主键、唯一键、数据不一致及DDL冲突。异步复制中可通过设置只读、跳过错误或手动修复处理冲突；多主复制需通过分配写负载、配置自增参数、使用GTID等预防冲突；组复制则基于写集检测冲突，后提交事务回滚。关键在于合理设计架构，避免多点写入，强化监控与维护。
MySQL 复制冲突通常出现在主从复制或组复制环境中，当多个节点尝试修改同一数据时可能发生。处理这类问题需要根据复制类型（异步、半同步、组复制等）和具体场景采取不同策略。
理解复制冲突的常见类型
在 MySQL 中，复制冲突主要表现为以下几种情况：
- 主键冲突：从库插入已存在的主键值。
- 唯一键冲突：违反唯一索引约束，如重复的邮箱或用户名。
- 数据不一致：主从数据内容不同，导致 SQL 线程执行失败。
- DDL 冲突：在多主复制中，不同节点对同一表执行结构变更。
异步复制中的冲突处理方法
标准的主从异步复制是单向的，正常情况下不会出现写冲突。但如果误操作在从库写入数据，就可能引发冲突。
- 设置从库为只读：readonly 可防止意外写入，减少冲突风险。
- 跳过错误事务：对于非关键错误，可通过 SET GLOBAL sql_slave_skip_counter = 1 跳过当前错误事件（需谨慎使用）。
- 手动修复数据：停止复制，修正从库数据后重新启动复制线程。
- 使用 pt-slave-restart 工具自动重启复制并跳过指定错误。
多主或环形复制中的冲突预防
多主复制容易产生写冲突，必须通过设计规避。
- 分配写负载：让不同节点负责不同的表或业务模块，避免同时写同一行。
- 使用全局事务ID（GTID）：便于追踪和管理事务来源，提升一致性维护能力。
- 启用 auto_increment_increment 和 auto_increment_offset，确保自增主键不重复。
- 监控复制延迟和错误日志，及时发现潜在问题。
MySQL Group Replication 的内置冲突检测
MySQL 组复制支持多主模式，并提供冲突检测机制。
- 基于写集合（write set）对比：如果两个事务修改同一行且未按相同顺序提交，则判定为冲突。
- 冲突解决策略：后提交的事务会被回滚，保证最终一致性。
- 应用层应处理因事务回滚导致的错误，重试逻辑需合理设计。
基本上就这些。关键是根据架构选择合适的复制方式，尽量避免多点写入，加强监控与维护。即使有冲突处理机制，也不能替代良好的系统设计。
