MySQL主从复制中断时，先用SHOW SLAVE STATUS\G检查Seconds_Behind_Master、Slave_IO_Running和Slave_SQL_Running状态，再根据IO_Error或SQL_Error定位网络、权限、binlog缺失或数据不一致问题。
主从复制中断时如何快速定位错误类型
MySQL 主从复制中断后，SHOW SLAVE STATUS\G 是第一响应命令。重点看 Seconds_Behind_Master 是否为 NULL，以及 Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes。若其中任一为 No，需进一步查 IO_Error 或 SQL_Error 字段——前者多为网络、权限、binlog 文件缺失问题；后者才是真正的数据不一致或语句执行失败，比如主库执行了 DROP TABLE，但从库该表已被手动删过，就会报 ERROR 1051 (42S02)。
跳过单条 SQL 错误的实操步骤与风险控制
仅当确认出错语句可安全忽略（如重复插入、已存在的 DDL）时，才用跳过方式恢复同步。操作前必须备份从库当前状态（至少 mysqldump --single-transaction 导出关键库）。跳过逻辑依赖 sql_slave_skip_counter，但该变量在 GTID 模式下不可用——务必先确认：
SELECT @@GLOBAL.gtid_mode;若返回
ON，则必须改用 SET GTID_NEXT + 空事务方式跳过：
SET GTID_NEXT='xxx-xxx-xxx:12345'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';
其中 xxx-xxx-xxx:12345 需替换为报错事件对应的 GTID 值，可通过 SHOW BINLOG EVENTS IN 'mysql-bin.000001' FROM 12345 LIMIT 1 查得。
基于 relay log 手动重放修复数据不一致
当跳过导致从库数据落后于主库（如漏掉几条 UPDATE），不能只靠 START SLAVE 恢复，需人工补数据。核心是解析 relay log 获取缺失变更：
mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/relay-bin.000002 | grep -A 20 "table_name"找到对应
UPDATE 或 INSERT 的行事件后，提取 SET @1=... @2=... 变量，转换为可执行 SQL。注意：relay log 默认不记录完整 SQL，开启需在从库配置 log_slave_updates=ON（重启生效），否则只能靠 row 格式反推，复杂度陡增。
修复后验证主从一致性不能只看 Seconds_Behind_Master
Seconds_Behind_Master = 0 仅表示 SQL 线程追平了 relay log，并不保证数据一致。必须做校验：
- 用
pt-table-checksum对全库逐表计算 CRC32 校验和（推荐，支持在线、断点续校） - 对关键业务表，直接比对主从的
COUNT(*)和MIN(id), MAX(id)（适合无删除场景） - 检查
SHOW MASTER STATUS与SHOW SLAVE STATUS中的Exec_Master_Log_Pos和Read_Master_Log_Pos是否相等且稳定
pt-table-sync 可生成修复语句，但务必先在测试环境验证，再人工审核后执行。 
