遇到“复制错误 _mysql”需先通过SHOW SLAVE STATUS\G定位错误类型，仅在人为误操作、非关键DML失败或GTID重复等安全场景下跳过；推荐GTID方式跳过，传统binlog位置跳过风险高；预防重于修复，应设read_only、统一配置、避开高峰操作并定期校验数据一致性。

遇到“复制错误 _mysql”通常指 MySQL 主从复制过程中出现中断，比如主从数据不一致、SQL 线程报错、GTID 冲突或 relay log 损坏等。跳过错误不能一概而用，需先判断错误类型和业务影响，再选择安全方式恢复复制。

确认错误类型和是否可跳过

登录从库执行：
SHOW SLAVE STATUS\G
重点关注：
• Seconds_Behind_Master：是否为 NULL 或 0
• Slave_IO_Running 和 Slave_SQL_Running：哪个线程停止了
• SQL_Delay 和 SQL_Remaining_Delay：是否有延迟复制设置
• Last_SQL_Error：具体报错内容（如“Duplicate entry”、“No such table”、“GTID already executed”）

只有以下情况才建议跳过：
• 错误由人为误操作（如从库手动改数据）引起，且主库已修复
• 非关键 DML（如日志表 INSERT 失败），跳过不影响业务一致性
• GTID 模式下重复执行已存在事务（Errno 1062 / 1032 / 1236 等常见可跳过类）
严禁跳过：表结构变更失败、主键冲突但业务强依赖、relay log 损坏无法定位位置等。

基于 GTID 的跳过方法（推荐）

适用于 gtid_mode = ON 的环境，更安全可控：

• 查出当前卡住的 GTID（在 Last_SQL_Error 中一般会显示类似 a1b2c3d4-5678-90ab-cdef-1234567890ab:12345）
• 生成一个空事务覆盖它：
  SET GTID_NEXT='a1b2c3d4-5678-90ab-cdef-1234567890ab:12345';
  BEGIN; COMMIT;
  SET GTID_NEXT='AUTOMATIC';
• 重启 SQL 线程：
  START SLAVE SQL_THREAD;

传统 binlog 位置跳过（仅限 gtid_mode = OFF）

风险较高，需确保跳过的事件确实无业务影响：

• 记录当前 Relay_Master_Log_File 和 Exec_Master_Log_Pos
• 在主库查该位置对应事件：
  mysqlbinlog --base64-output=decode-rows -v master-bin.000001 | grep -A 20 "at 12345"
• 若确认可跳，从库执行：
  STOP SLAVE;
  CHANGE MASTER TO MASTER_LOG_FILE='master-bin.000001', MASTER_LOG_POS=12346;
  START SLAVE;

预防比跳过更重要

多数复制错误源于配置或操作疏漏：

• 从库设为 read_only = ON（除复制用户外禁止写入）
• 主从使用相同版本、字符集、sql_mode，避免隐式转换差异
• 批量更新/DDL 操作避开业务高峰，并在从库提前验证
• 启用 slave_skip_errors 要极度谨慎（如只设 1032,1062），切勿设为 ALL
• 定期校验主从数据一致性（用 pt-table-checksum）