MySQL主从配置中Slave_SQL_Running为No，如何排查并解决错误码问题？

本文共计1115个文字，预计阅读时间需要5分钟。

直接查看+Last_SQL_Error，它比任何经验都更准——错误码（如：

查错必须先看 Last_SQL_Error 而不是急着 START SLAVE

当 SHOW SLAVE STATUS\G 显示 Slave_SQL_Running: No，第一反应不是重启或跳过，而是立刻定位 SQL 线程卡在哪条语句。关键字段是：

• Last_IO_Errno 和 Last_IO_Error：I/O 线程问题（比如网络断开、权限不对、auto.cnf 中 server_uuid 冲突）
• Last_SQL_Errno 和 Last_SQL_Error：SQL 线程执行失败，这才是数据一致性的真正风险点

常见错误码含义：

• 1032：Can't find record in 'xxx' —— 主库删/改了某行，从库已不存在该记录（典型数据漂移）
• 1062：Duplicate entry 'xxx' for key 'PRIMARY' —— 主库插入了一条从库已存在的主键记录
• 1205：Deadlock found when trying to get lock —— 行锁冲突，多见于高并发写入场景
• 1213：Lock wait timeout exceeded —— 锁等待超时，常因长事务或未提交事务阻塞

注意：Last_SQL_Error 在 RBR（默认）模式下通常不显示具体 SQL，只提示事务 ID 和 binlog 位置，这时必须靠 mysqlbinlog 解析。

跳过错误不能无脑用 SQL_SLAVE_SKIP_COUNTER=1

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 是临时跳过当前事务的“止血针”，但有严格前提：

• 仅对 SBR（基于语句的复制）可靠；MySQL 5.7+ 默认是 RBR（基于行），跳过可能跳掉部分变更，导致后续主从不一致
• 只适用于单次偶发错误，比如一条误删引发的 1032，且确认主库该操作合理、从库缺失可接受
• 执行前必须 STOP SLAVE，执行后 START SLAVE，否则无效
• 跳过后务必再查 Seconds_Behind_Master 是否归零，并比对关键表数据

绝对禁止配置 slave_skip_errors = all：它会掩盖主键冲突、外键约束失败、DDL 执行失败等严重问题，生产环境等于自废监控。

遇到 1032 或 1062 应优先手动修复而非跳过

这两类错误本质是主从数据不一致，跳过只是绕开症状，不解决病根。正确路径是：

• 对 1062（主键重复）：登录从库，DELETE FROM table_name WHERE id = X; 删除冲突行，再 START SLAVE
• 对 1032（记录不存在）：先确认主库是否真删了该行（查 binlog 或业务日志），若属实，从库无需补数据，直接跳过；若主库没删，说明从库误删，需从备份恢复或用 mysqlbinlog 回放缺失变更
• RBR 下定位不到具体语句？用 mysqlbinlog --base64-output=decode-rows -v --start-position=A --stop-position=B /var/lib/mysql/mysql-bin.0000xx 解析出错事务的原始变更

特别注意：所有手动 DML 操作（如 DELETE）在从库执行前，必须确保 sql_log_bin = 0，否则会写入自身 binlog，造成环形复制或二次冲突。

Slave_IO_Running: No 和 Slave_SQL_Running: No 必须分开诊断

这两个线程职责不同，故障原因几乎不重叠：

• Slave_IO_Running: No → I/O 线程无法连接主库或读取 binlog，重点查：auto.cnf 中 server_uuid 是否与主库重复（克隆虚拟机常见）、主库防火墙/端口、复制账号权限、MASTER_HOST 是否可解析（建议配 skip-name-resolve）
• Slave_SQL_Running: No → 已成功拉取中继日志，但执行失败，核心就是 Last_SQL_Error 和对应错误码

一个容易被忽略的细节：如果从库曾被手动写入（哪怕只是一条 INSERT），就可能破坏 GTID 一致性或导致 position 偏移，此时 CHANGE MASTER TO 强制指定位点反而更稳妥，但要承担丢数据风险。