主从复制冲突因数据不一致导致，需谨慎处理。先通过SHOW SLAVE STATUS识别错误类型，如主键冲突或记录不存在；应急时可跳过单个错误事件，但有风险；建议启用GTID模式减少重复事务冲突；数据差异大时应使用mysqldump或XtraBackup重新同步；预防上禁止写从库、监控延迟与一致性，定期校验数据。

mysql主从复制出现冲突时，通常是因为主库和从库的数据不一致，导致从库在重放二进制日志（binlog）时执行失败。处理这类问题需要谨慎，既要保证数据一致性，又要尽量减少服务中断。以下是常见的处理方式和建议。

1. 识别复制冲突类型

常见的复制冲突包括：

• 主键冲突：从库插入已存在的主键或唯一键。
• 记录不存在：从库执行UPDATE或delete时找不到对应行。
• SQL线程报错：通过SHOW SLAVE STATUSG查看Last_SQL_Error字段可定位具体错误。

例如错误信息可能显示“Duplicate entry ‘xxx’ for key ‘PRIMARY’”，说明发生了主键重复。

2. 短期应急处理：跳过错误

在非关键业务或明确知道不影响数据完整性的场景下，可以临时跳过错误。

• 跳过一个错误事件：
  STOP SLAVE;
  SET GLOBAL sql_slave_skip_counter = 1;
  START SLAVE;
• 适用于偶发性、可忽略的错误，如临时表操作或测试数据写入。

注意：此方法风险较高，可能导致主从数据进一步不一致，仅建议用于紧急恢复。

云从科技AI开放平台

云从AI开放平台

51

查看详情

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工具。

基本上就这些。关键是根据实际场景选择跳过、修复还是重建，同时建立预防机制减少问题发生。