一、问题背景

场景：

  • MySQL 主从复制环境
  • 从库（Slave/Replica）宕机一段时间
  • 从库重启后，同步主库时出现主键冲突错误

错误示例：

ERROR 1062 (23000): Duplicate entry '123' for key 'PRIMARY'

二、常见原因

1️⃣ 主从写入不一致（双写 / 并行写入）

  • 如果从库在宕机期间被错误写入（直接写操作或误用），会导致主从数据不一致
  • 主库已有的数据和从库新写入的数据产生冲突

2️⃣ 自增主键配置问题（AUTO_INCREMENT）

  • MySQL 并行复制或主从配置不当，会导致 AUTO_INCREMENT 值重复
  • 相关参数：
参数作用
auto_increment_increment步长，防止多主复制冲突
auto_increment_offset起始偏移值
默认单主复制：步长=1，偏移=1，多主复制需修改以避免冲突

3️⃣ 并行复制与事务冲突

  • MySQL 5.7+ 支持 多线程复制（MTS / slave_parallel_workers）
  • 从库宕机后，重放 binlog 可能出现：
    • 顺序重放异常
    • 并行执行导致主键重复

4️⃣ 主从复制中断导致脏数据

  • 从库宕机期间：
    • 主库继续写入
    • 从库本地手动写入或应用写入
  • 恢复复制时，binlog 重放就会出现冲突

三、排查步骤

  1. 查看从库状态：
SHOW REPLICA STATUS\G

重点字段：

  • Slave_IO_Running / Slave_SQL_Running → 是否正常
  • Last_Errno / Last_Error → 错误信息
  • Exec_Master_Log_Pos / Relay_Master_Log_File → 当前执行位置
  1. 查看冲突的主键：
SELECT * FROM table_name WHERE id = 123;
  1. 检查 AUTO_INCREMENT 设置：
SHOW VARIABLES LIKE 'auto_increment%';

四、解决方案

1️⃣ 修复冲突数据（慎重操作）

  • 如果冲突数据可丢弃，可删除从库冲突行：
DELETE FROM table_name WHERE id = 123;
  • 然后 跳过错误继续复制：
STOP REPLICA;
SET GLOBAL sql_slave_skip_counter = 1;
START REPLICA;

⚠️ 注意：跳过错误会丢失该事务，必须确认业务允许

2️⃣ 修正 AUTO_INCREMENT 参数

单主复制：

-- 保持默认即可
auto_increment_increment = 1
auto_increment_offset = 1

多主复制：

[mysqld]
server-id = 1
auto_increment_increment = 2
auto_increment_offset = 1

-- 另一台主库
server-id = 2
auto_increment_increment = 2
auto_increment_offset = 2
  • 这样不同主库生成的自增主键不会重复

3️⃣ 全量重新同步（最安全）

  1. 从库宕机严重或数据脏乱 → 停止复制：
STOP REPLICA;
RESET REPLICA ALL;
  1. 使用 mysqldump 或 Percona XtraBackup 从主库重新同步
  2. 重新启动复制：
CHANGE REPLICA TO
SOURCE_HOST='master_ip',
SOURCE_USER='repl_user',
SOURCE_PASSWORD='password',
SOURCE_LOG_FILE='最新binlog',
SOURCE_LOG_POS=最新位置;
START REPLICA;

✅ 优点：彻底解决主键冲突和数据不一致问题
❌ 缺点：数据量大时耗时长

4️⃣ 监控与防护措施

  • 使用 只读从库，避免宕机期间写入
  • 定期监控复制延迟：
SHOW REPLICA STATUS\G
  • 配置 auto_increment_increment / offset 以支持多主场景
  • 重要数据表可增加 唯一约束/业务逻辑校验

五、总结

问题类型原因解决方案
宕机期间从库被写数据不一致删除冲突数据 + 跳过错误
AUTO_INCREMENT 冲突多主或 MTS 配置不当调整 auto_increment_increment/offset
并行复制冲突多线程复制降低并行度或重建复制
数据脏乱长时间宕机全量同步，从主库重新拉取数据

💡 核心原则

  1. 从库宕机期间不要写数据 → 保证主从一致
  2. 多主复制必须配置自增偏移 → 避免主键冲突
  3. 出现主键冲突可跳过或全量同步 → 根据业务允许选择
  4. 监控复制延迟 → 避免问题积累