遇到“复制错误 _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）
风险较高，需确保跳过的事件确实无业务影响：
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
- 记录当前 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）
