主从复制中断后如何快速定位错误位置
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 SLAVEGTID 模式：执行
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 上。
