我之前搭建主主复制时也踩过一模一样的主键重复坑，咱们一步步来解决这个问题：

问题根源分析 #

你遇到的Duplicate entry '1576' for key 'PRIMARY'错误，核心原因有两个：

1. 主键自增规则冲突：主主复制如果没配置自增步长和偏移量，两个节点会生成相同的主键ID，当一边的写入同步到另一边时，就会触发主键重复报错。
2. 初始数据不一致：搭建主从时，两边的nagiosxi.xi_auditlog表可能已经存在重叠的主键数据，导致同步时冲突。

分步解决方案 #

1. 配置主键自增规则（核心必做） #

这是从根源避免主键重复的关键，给两个节点设置不同的自增起始值和相同的步长：

• 登录第一个主库（假设为Node A），修改MySQL配置文件my.cnf（Windows是my.ini）：

  auto_increment_increment = 2  # 每次自增步长为2
  auto_increment_offset = 1     # 起始值为1，生成1、3、5...的主键
  

• 登录第二个主库（Node B），修改配置文件：

  auto_increment_increment = 2
  auto_increment_offset = 2     # 起始值为2，生成2、4、6...的主键
  

• 重启两个MySQL服务使配置生效；如果不想重启，也可以临时执行全局变量命令（重启后失效，建议写到配置文件）：

  -- Node A执行
  SET GLOBAL auto_increment_increment=2;
  SET GLOBAL auto_increment_offset=1;
  
  -- Node B执行
  SET GLOBAL auto_increment_increment=2;
  SET GLOBAL auto_increment_offset=2;
  

2. 修复当前的重复数据错误 #

先处理已经触发的同步错误，让复制恢复正常：

• 暂停从库的复制进程：

  STOP SLAVE;
  

• 根据错误数量选择跳过方式：
  • 少量错误：跳过单个报错的事务：

    SET GLOBAL sql_slave_skip_counter = 1;
    START SLAVE;
    

    执行后检查SHOW SLAVE STATUS\G，看Last_SQL_Error是否为空，Slave_SQL_Running是否为Yes。
  • 大量错误：临时跳过所有主键重复错误（仅救急，后续要移除）：
    在从库的my.cnf中添加：

    slave_skip_errors = 1062  # 1062是主键重复的错误码
    

    重启MySQL后启动复制：

    START SLAVE;
    

    等同步正常后，一定要去掉这个配置，因为跳过错误可能导致数据不一致。
• 校验数据一致性：
  对比两个节点的表数据，比如执行：

  CHECKSUM TABLE nagiosxi.xi_auditlog;
  

  如果校验和不一致，需要手动同步：先停复制，用mysqldump导出主库的表数据，导入从库，再重新启动复制。

3. 确认主主复制的双向配置 #

确保两个节点都正确配置了双向复制：

• 两个节点的server-id必须唯一（你已经完成主从连接，大概率没问题，但再核对下）
• 每个节点都开启了二进制日志log_bin = ON
• 每个节点都作为对方的从库，配置了正确的master_host、master_user、master_password以及对应的二进制日志文件和位置，且Slave_IO_Running和Slave_SQL_Running都为Yes

4. 是否需要脚本？ #

脚本不是解决核心问题的必须项，但可以辅助运维：

• 可以写简单的Shell/Python脚本，定期执行SHOW SLAVE STATUS\G，监控复制状态（比如检查两个Running状态、错误信息），一旦异常发送告警。
• 但核心问题还是配置层面的主键自增规则和初始数据一致性，脚本只是辅助监控手段。

内容的提问来源于stack exchange，提问作者John smith