MySQL复制中断后应先通过SHOW SLAVE STATUS/G聚焦Exec_Master_Log_Pos和Relay_Master_Log_File定位错误位置，再结合GTID状态、连通性及binlog保留情况排查；跳过错误需按模式选择sql_slave_skip_counter或GTID_NEXT空事务；修复数据不一致优先用pt工具校验同步，手动修复须禁用binlog并验证复制稳定性。
主从复制中断后如何快速定位错误位置
MySQL 复制中断时，SHOW SLAVE STATUS/G 是第一入口，但关键不是看整体状态，而是盯住三个字段：Seconds_Behind_Master（是否真延迟）、SQL_Delay（是否人为延迟）、以及最关键的 Exec_Master_Log_Pos 和 Relay_Master_Log_File —— 它们共同定义了从库当前执行到主库 binlog 的哪个位置。
常见误判是看到 Slave_IO_Running: Yes 且 Slave_SQL_Running: No 就直接跳去查 error log，其实应先比对 Master_Host 连通性、Retrieved_Gtid_Set 与 Executed_Gtid_Set 是否存在 gap（GTID 模式下），再确认是否因主库 binlog 被 purge 导致 Could not find first log file name in binary log index file 错误。
跳过单条报错语句的几种安全方式
跳过错误不能只靠 SET GLOBAL sql_slave_skip_counter = 1，该命令仅在非 GTID 模式下有效，且跳过的是 relay log 中的下一个 event，不是“当前卡住的那条”。GTID 模式下必须用 SET GTID_NEXT + 空事务方式绕过。
- 非 GTID 模式：先
STOP SLAVE，再SET GLOBAL sql_slave_skip_counter = 1，然后START SLAVE - GTID 模式：执行
STOP SLAVE→SET GTID_NEXT = 'xxx-xxx-xxx:nnn'（值来自SHOW SLAVE STATUS/G中的Retrieved_Gtid_Set缺失项）→BEGIN; COMMIT;→SET GTID_NEXT = 'AUTOMATIC'→START SLAVE - 无论哪种模式，跳过前务必用
mysqlbinlog -v --base64-output=DECODE-ROWS解析对应 binlog 文件和 position，确认跳过的确实是可丢弃的语句（如重复插入、被删表的 DDL）
从库数据不一致时如何最小化修复
不要一上来就全量重建从库。先用 pt-table-checksum 扫描差异表，再用 pt-table-sync 生成修复 SQL —— 但注意它默认输出的是「在从库上执行的反向语句」，若网络或权限受限，需加 --sync-to-master 改为在主库执行变更并让从库自动同步。
手动修复时，避免直接 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE INTO，它们会改变 auto-increment 值或触发额外 binlog event；更稳妥的是先 DELETE 再 INSERT，并确保语句带 SET SQL_LOG_BIN = 0（仅限从库会话内），防止修复操作又被复制回主库造成循环。
SET SQL_LOG_BIN = 0; DELETE FROM orders WHERE id = 12345; INSERT INTO orders VALUES (12345, 'pending', '2024-06-01'); SET SQL_LOG_BIN = 1;
恢复后必须验证的三个动作
启动复制只是第一步。真正容易被忽略的是验证环节：
- 检查
Seconds_Behind_Master是否持续归零，而非短暂跳变后又涨起（可能隐含主从 schema 不一致导致后续 event 再次失败） - 对比主从的
SELECT COUNT(*)和CHECKSUM TABLE结果，尤其关注大表和近期高频更新的表 - 在从库执行
SHOW PROCESSLIST，确认没有长时间运行的System lock或Waiting for table metadata lock，这类锁常源于未提交事务或 DDL 阻塞
GTID 模式下还要额外跑一次 SELECT * FROM performance_schema.replication_applier_status_by_coordinator，确认 coordinator 线程没卡在某个 transaction 上。