MySQL主从同步故障中Slave_SQL_Running: No是什么原因怎么解决

MySQL主从同步是很多业务场景下的标准数据库部署方案，能够有效分担主库读压力，同时实现数据容灾备份。当出现Slave_SQL_Running: No的故障时，从库会停止执行主库同步过来的relay log中的SQL语句，数据同步进程中断，需要及时处理避免数据长期不一致。

故障常见原因

1. 从库执行SQL时出现错误

最常见的原因是主库同步过来的SQL语句在从库执行失败，比如从库不存在对应的表、字段不匹配、权限不足等。例如主库新增了一个字段，从库表结构没有同步更新，执行ALTER语句时就会报错。

2. 主从数据不一致导致冲突

如果从库提前存在和主库要插入的数据主键冲突的记录，或者要删除的记录在从库不存在，就会触发执行错误。比如在从库手动插入了一条id=10的记录，主库后续插入id=10的数据时，从库执行就会报主键重复错误。

3. 从库relay log损坏

从库的中继日志relay log如果出现损坏，SQL线程读取到不完整的日志内容时也会停止运行，状态变为No。

故障排查步骤

首先登录从库MySQL，执行以下命令查看同步状态：

SHOW SLAVE STATUS\G

重点关注以下几个字段：

• Last_SQL_Error：会显示SQL线程停止的具体错误信息，是定位问题的核心依据
• Last_SQL_Errno：对应的错误编号
• Relay_Master_Log_File：当前SQL线程正在读取的主库binlog文件名
• Exec_Master_Log_Pos：当前SQL线程执行到的主库binlog位置点

对应解决方法

方法1：跳过错误事务（适用于非核心数据不一致场景）

如果错误是偶发的、不影响业务数据一致性，可以跳过对应的错误事务。如果是单个错误，可以设置跳过错误数：

-- 停止从库同步线程
STOP SLAVE;
-- 设置跳过1个错误事务，根据具体错误数量调整
SET GLOBAL sql_slave_skip_counter = 1;
-- 重新启动从库同步
START SLAVE;

也可以修改从库配置文件，设置跳过指定的错误编号，比如跳过主键重复错误1062和记录不存在错误1032：

[mysqld]
slave-skip-errors=1062,1032

修改后重启MySQL服务，再启动从库同步即可。

方法2：重新同步不一致的表（适用于数据不一致场景）

如果是因为表数据不一致导致的错误，可以重新同步对应表的数据。步骤如下：

首先在主库锁定要同步的表，避免同步过程中数据变化：

-- 锁定表为只读
FLUSH TABLES WITH READ LOCK;
-- 查看当前主库binlog位置
SHOW MASTER STATUS;

然后导出该表的数据：

mysqldump -u root -p 数据库名 表名 > 表名.sql

将导出的SQL文件传到从库，在从库恢复数据：

mysql -u root -p 数据库名 < 表名.sql

之后回到主库解锁表：

UNLOCK TABLES;

最后在从库重新设置同步起点，启动同步：

STOP SLAVE;
-- 根据之前主库SHOW MASTER STATUS的结果设置
CHANGE MASTER TO MASTER_LOG_FILE='主库binlog文件名', MASTER_LOG_POS=主库位置点;
START SLAVE;

方法3：修复损坏的relay log

如果是relay log损坏，可以重置从库的relay log，重新从主库拉取：

STOP SLAVE;
-- 重置relay log
RESET SLAVE;
-- 重新设置主库同步信息，根据实际情况填写
CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='同步账号', MASTER_PASSWORD='同步密码', MASTER_LOG_FILE='主库当前binlog文件', MASTER_LOG_POS=主库当前位置点;
START SLAVE;

预防措施

为了避免Slave_SQL_Running: No故障反复出现，日常运维中可以做好以下几点：

• 主从库的MySQL版本尽量保持一致，避免版本差异导致的语法兼容问题
• 禁止在从库手动执行写操作，避免数据不一致
• 主库表结构变更时，先在从库验证可行性，再同步执行
• 定期监控主从同步状态，发现延迟或异常及时处理

MySQL主从同步Slave_SQL_Running故障排查数据同步修改时间：2026-06-06 22:50:58