MySQL同步报错Slave_SQL_Running: No的解决方法

故障现象与原因分析

在执行 MySQL 主从同步测试或监控时，若发现从库未能与主库保持同步，查看从库状态（show slave status\G）通常会发现以下异常：

• Slave_IO_Running: Yes
• Slave_SQL_Running: No
• Last_Errno: 1062 （或其他特定错误码）
• Seconds_Behind_Master: NULL 或数值较大

导致该问题的常见原因包括：

1. 数据写入冲突： 程序或用户可能直接在从库（Slave）上进行了写操作，导致主从数据结构不一致。
2. 事务回滚： 从库机器重启后，正在执行的事务被中断或回滚，导致同步线程状态异常。

解决办法一：跳过错误继续同步（推荐尝试）

如果错误属于非致命的重复键值错误等，最简单的办法是跳过当前的错误事务，让从库继续读取并执行后续日志。

第1步：停止从库同步服务

首先暂停同步进程，防止在设置期间产生新的报错。

mysql> STOP SLAVE;

第2步：跳过指定数量的事务

执行全局变量设置，跳过接下来的 1 个事务（SQL语句）。如果存在多个连续的错误，可能需要多次执行或根据具体错误调整计数值。

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

第3步：重新启动从库同步

mysql> START SLAVE;

完成判断

再次运行 SHOW SLAVE STATUS\G，观察 Slave_SQL_Running 是否变为 Yes，且 Seconds_Behind_Master 逐渐归零。

解决办法二：强制重新设定同步起点

如果方法一无效，或者数据差异过大，可以从主库获取当前的二进制日志文件位置和位置点，手动将同步进度重置到该位置。注意，此方法可能导致自上次备份以来产生的部分数据丢失，请谨慎操作。

第1步：在从库停止同步

mysql> STOP SLAVE;

第2步：在主库查看当前同步位点

登录主库（Master），执行命令记录当前的 Binlog 文件名和 Position 号。

mysql> SHOW MASTER STATUS;

输出示例：

+------------------+-----------+--------------+------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.000020 | 135617781 |              |                  |
+------------------+-----------+--------------+------------------+

记下 File 列的值（如 mysql-bin.000020）和 Position 列的值（如 135617781）。

第3步：在从库重置同步配置

回到从库，使用 CHANGE MASTER TO 命令指定主库连接信息及上述的位点。请将以下参数替换为你的实际环境信息：

mysql> CHANGE MASTER TO 
    MASTER_HOST='master_ip',
    MASTER_USER='user',
    MASTER_PASSWORD='pwd',
    MASTER_PORT=3306,
    MASTER_LOG_FILE='mysql-bin.000020',
    MASTER_LOG_POS=135617781;

第4步：启动同步并验证

mysql> START SLAVE;

验证 SHOW SLAVE STATUS\G，确保 Slave_IO_Running 和 Slave_SQL_Running 均显示为 Yes。

注意事项

• 数据一致性风险： 方法二是一种“破坏性”的重置手段，可能会导致部分未应用的数据丢失。使用前建议评估数据损失是否在允许范围内。
• 权限要求： 以上操作需要具有 SUPER 权限的 MySQL 用户执行。
• 根本解决： 如果频繁出现同步错误，应检查应用程序是否正确地将写请求指向了主库，而不是直接写入从库。

以上就是解决 MySQL 主从同步 Slave_SQL_Running: No 错误的详细内容，更多关于 MySQL 数据库维护优化的资料请关注本站其它相关文章！