主从复制中断时如何快速定位错误位置
MySQL 主从复制中断后，
SHOW SLAVE STATUS\G是唯一可靠入口。重点关注
Seconds_Behind_Master（是否为
NULL）、
Slave_IO_Running和
Slave_SQL_Running是否都为
Yes，以及最关键的
SQL_Delay、
Exec_Master_Log_Pos和
Relay_Log_Pos是否停滞。
常见假象是 IO 线程正常但 SQL 线程卡住，此时
Seconds_Behind_Master显示非零或
NULL，而
Last_SQL_Error会明确报出具体语句和错误号（如
1062 Duplicate entry或
1032 Can't find record）。 若
Slave_IO_Running: No，优先检查网络连通性、主库
binlog是否开启、账号权限（
REPLICATION SLAVE）、主库
server_id是否唯一 若
Slave_SQL_Running: No，错误通常来自数据不一致（如从库误写、主库 DDL 未同步、GTID 模式下事务冲突），不能直接跳过，需人工核对
Relay_Log_Space持续增长但无进展，大概率是 SQL 线程被阻塞（如大事务未提交、锁等待），可用
SHOW PROCESSLIST查看
State字段是否为
Waiting for table metadata lock
跳过单条错误事务的实操边界
仅当确认该事务在从库无业务影响（例如主库执行了测试 INSERT，从库已存在相同主键）且无法回滚主库操作时，才考虑跳过。跳过方式取决于复制模式：
基于 binlog 位置（binlog_format=STATEMENT或
MIXED）：用
SET GLOBAL sql_slave_skip_counter = 1，再执行
START SLAVE；注意该命令仅对当前 relay log 有效，重启后失效 基于 GTID（
gtid_mode=ON）：必须用
SET GTID_NEXT='xxx-xxx-xxx:nnn'+
BEGIN; COMMIT;注入空事务，再
START SLAVE；错误的
GTID_NEXT值会导致后续复制彻底紊乱 严禁在生产环境批量跳过（如设为 100），这会掩盖真实数据偏差，后续校验成本远高于停机修复
从库误写导致主从不一致的紧急补救
一旦发现从库被直接写入（如应用连接错库、DBA 误操作），
STOP SLAVE是第一动作。此时不能简单重启复制——主库新写入会覆盖从库“脏数据”，造成不可逆丢失。
正确路径是先导出从库异常表的变更行（用
mysqldump --where或解析
relay-log找出 INSERT/UPDATE/DELETE），再对比主库对应时间点的 binlog，判断哪些是冗余写入、哪些是缺失同步。工具上可借助
pt-table-checksum和
pt-table-sync，但需注意：
pt-table-sync默认生成
REPLACE INTO，若从库有额外索引或触发器，可能引发意外行为 跨版本同步（如主库 8.0，从库 5.7）时，
JSON或
Generated Column类型字段会失败，必须提前过滤 大表修复期间，务必关闭
slave_parallel_workers，避免并行应用加剧不一致
配置参数错误引发的隐性故障
很多主从异常并非复制链路断开，而是配置项逻辑冲突。典型例子：
replicate-ignore-db=test在语句级复制下完全失效（因为 USE test; INSERT INTO otherdb.t1 不会被忽略），必须改用
replicate-wild-ignore-table=test.%。
其他高危配置：
innodb_flush_log_at_trx_commit=2+
sync_binlog=0组合：主库崩溃可能导致已提交事务丢失，从库永远追不上，且无错误提示
slave_net_timeout过大（如设为 3600）：IO 线程在主库短暂不可达时不会及时重连，表现为长时间
Seconds_Behind_Master持续增加
max_allowed_packet主从不一致：主库允许大包，从库拒绝解析，SQL 线程报错
Packet too large，但错误日志可能被淹没在常规 warning 中
修复这类问题必须逐项比对主从
my.cnf中所有以
replicate-、
slave-、
binlog-开头的参数，而不是只盯着
CHANGE MASTER TO语句。
