mysql主从复制中的延迟与错误排查

准确判断主从延迟应比对binlog位置（Read_Master_Log_Pos与Exec_Master_Log_Pos）或GTID集合（gtid_executed、Retrieved_Gtid_Set、Executed_Gtid_Set），而非依赖Seconds_Behind_Master；常见错误1032、1062、2003需结合Last_SQL_Errno/Last_SQL_Error定位处理。

查看主从延迟的准确方法

仅看 Seconds_Behind_Master 不可靠，尤其在从库 IO 线程异常或 relay log 未更新时，该值可能固定为 NULL 或 0，但实际已落后。真正有效的判断方式是比对主从的 binlog 位置和 GTID 集合。

• 在从库执行 SHOW SLAVE STATUS\G，重点关注 Read_Master_Log_Pos（IO 线程读到的位置）和 Exec_Master_Log_Pos（SQL 线程执行到的位置），两者差值过大说明 SQL 线程积压
• 若启用 GTID，对比主库的 SELECT @@global.gtid_executed; 和从库的 Retrieved_Gtid_Set、Executed_Gtid_Set，三者不一致即存在延迟或断点
• 避免依赖 pt-heartbeat 的单点时间戳——它只反映心跳表更新延迟，无法覆盖 DDL、大事务或复制过滤场景

常见复制错误类型与快速定位命令

MySQL 复制中断时，Slave_SQL_Running: No 是表象，关键要看 Last_SQL_Errno 和 Last_SQL_Error 字段。不同错误需不同处理路径，不能一概跳过。

• Last_SQL_Errno: 1032：从库找不到要更新/删除的行 → 检查是否主库有 binlog_format = STATEMENT + 非确定性函数，或从库被误写入；用 mysqlbinlog --base64-output=DECODE-ROWS -v 解析对应 binlog 事件确认操作内容
• Last_SQL_Errno: 1062：唯一键冲突 → 常见于多源复制、手动插入或自增列未设 auto_increment_offset/auto_increment_increment；先确认冲突记录是否应存在，再决定是跳过（SET GLOBAL sql_slave_skip_counter = 1）还是修复数据
• Last_SQL_Errno: 2003 / 2013：网络类错误 → 查 Slave_IO_Running 状态，检查主库 max_connections 是否耗尽、防火墙是否拦截 3306、从库 master_host 配置是否为域名且 DNS 不稳定

修复延迟积压的实操策略

当 Exec_Master_Log_Pos 落后数 GB 时，盲目重启 SQL 线程或调大 slave_parallel_workers 可能加剧问题。优先确认积压是否由单一大事务引起。

• 用 SHOW PROCESSLIST 在从库中找状态为 Reading event from the relay log 或长时间 Updating 的线程，结合 information_schema.INNODB_TRX 查事务持续时间
• 若确认是单个大事务（如 DELETE FROM huge_table WHERE create_time ），不要 kill，而是等其完成；否则可能触发回滚并锁表更久
• 对持续写入型延迟，可临时启用并行复制：SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers = 4;，但需确保主库 binlog_transaction_dependency_tracking 为 WRITESET 或 WRITESET_SESSION
• 禁用 innodb_flush_log_at_trx_commit = 2 和 sync_binlog = 0 可提升从库回放速度，但会牺牲崩溃安全性，仅限临时应急

GTID 复制下跳过错误的正确姿势

开启 GTID 后，不能再用 sql_slave_skip_counter，必须用 gtid_next 注入空事务。操作不当会导致 GTID 集合错乱，后续无法重建复制关系。

• 先停复制：STOP SLAVE;
• 查当前报错事务的 GTID：SELECT @@global.gtid_executed; 和 SHOW SLAVE STATUS\G 中的 Retrieved_Gtid_Set
• 假设出错 GTID 是 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1001，执行：

  SET GTID_NEXT='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1001';
  BEGIN;
   COMMIT;
  SET GTID_NEXT='AUTOMATIC';

• 再 START SLAVE;，观察 Executed_Gtid_Set 是否向前推进
• 注意：跳过的 GTID 必须存在于 Retrieved_Gtid_Set 中，否则会报错 Could not execute because of problems with GTID consistency

GTID 模式下跳过事务是精确到每个事务的原子操作，少一个字符或顺序错位都会导致复制永久中断。生产环境执行前，务必在测试实例上完整复现并验证。