MySQL主从同步Slave_IO/SQl_Running为No的故障排查与恢复

Mason

发布时间：2026-10-13| 3人浏览过

原创

在MySQL主从复制架构中，Slave_IO_Running或Slave_SQL_Running变为No是常见的同步中断现象。这通常源于网络连接问题、权限缺失、包大小限制或从库执行冲突。通过检查错误日志、调整关键参数或重置同步位点，可以快速修复并恢复数据一致性。

结果或目标

解决MySQL从库同步中断问题，确保主库（Master）的数据变更能正常传输并在从库（Slave）上执行，最终使Slave_IO_Running: Yes和Slave_SQL_Running: Yes同时成立。

准备条件

具备主从服务器的主机访问权限（SSH/终端）。
拥有MySQL数据库的管理员账户，能够执行SHOW SLAVE STATUS和STOP SLAVE等命令。
了解主库当前使用的二进制日志文件名及位置坐标。

真实操作顺序

第1步：诊断Slave_IO_Running: No（I/O线程停止）

目的：I/O线程负责从主库拉取二进制日志。若该线程停止，说明数据传输层受阻。

入口：通过命令行连接至MySQL从库，执行：
SHOW SLAVE STATUS\G

动作：观察输出中的Slave_IO_Running字段是否为No，并结合Last_Errno和Last_Error分析原因。常见情况及处理如下：

网络或防火墙阻断：检查主从之间的端口连通性（默认3306）。若使用虚拟机NAT模式，需确认路由配置是否正确允许跨网段通信。
配置文件参数错误：检查主库my.cnf中的server-id是否唯一，且未误设只读选项影响同步用户权限。
权限不足：确保用于同步的用户（如replicuser）拥有REPLICATION SLAVE和FILE权限。若无全量权限至少需授予这两项。
GRANT REPLICATION SLAVE, FILE ON *.* TO 'replicuser'@'%'; FLUSH PRIVILEGES;

第2步：诊断Slave_SQL_Running: No（SQL线程停止）

目的：SQL线程负责重放中继日志中的事件。若停止，通常是因为执行了导致错误的语句（如主键冲突、表不存在等），MySQL出于自我保护暂停了回放。

入口：同上，查看SHOW SLAVE STATUS\G输出中的Last_Error。

动作：根据错误类型选择恢复策略：

跳过一个错误事件：如果确定该错误不影响数据一致性（例如重复插入相同记录，或非关键表的写入冲突），可临时跳过该步骤。
注意：必须先停止从库进程再设置计数器，否则报错。
```
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;
```
原理：该全局变量指定跳过接下来的N个从主库传来的事件。
手动补全缺失操作：若Last_Error提示需要在从库手动运行某条SQL（如INSERT INTO...），则先在从库执行该语句，然后再跳过当前错误：
```
-- 在执行具体的修复SQL后
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;
```

第3步：重置同步位点（针对日志损坏或位置错位）

目的：当发生断电、崩溃导致二进制日志损坏（如错误代码1236: impossible position），或者中继日志严重断裂时，可能需要强制从一个新的日志位置开始同步。

入口：主库查询当前状态：
SHOW MASTER STATUS\G

动作：若旧日志已损坏无法读取，放弃继续同步该日志，转而指向最新的主库日志文件：

停止从库同步：
STOP SLAVE;
更新主库信息：将新的日志文件和位置填入配置。
CHANGE MASTER TO MASTER_LOG_FILE='mysqlmaster.000080', MASTER_LOG_POS=0;
其中‘mysqlmaster.000080’和‘0’应替换为主库实际输出的最新文件名和位置。
重启同步：
START SLAVE;

此后观察Slave_IO_Running应恢复为Yes，数据将从新位置开始追赶。

第4步：验证恢复状态

目的：确认同步链路畅通且正在运行。

入口：
SHOW SLAVE STATUS\G

重要参数检查：

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 初始可能较高，随时间推移逐渐减小并最终归零，表示已追上。
无新增的Last_Errno错误。

完成判断

当SHOW SLAVE STATUS显示两个Running均为Yes，且Seconds_Behind_Master稳定或归零，即判定同步恢复正常。

原文有依据的排错

Error 1236 (Client requested master to start replication from impossible position)：通常因主库宕机未正常关闭Binlog导致日志截断或损坏。此时旧的Log File/Pos失效，必须使用CHANGE MASTER TO切换到下一个完好的Binlog文件重新开始。
Slave_SQL_Running: No 但 Last_Errno 为 1053：表示主库执行期间出错被中止，从库尝试应用不完整的事务。可通过跳过计数或直接重新运行报错SQL来解决。

简要总结

MySQL同步中断的核心在于“看日志定性质”。网络与权限问题多导致I/O线程停止；业务逻辑错误或异常中断多导致SQL线程停止。前者需查配置与网络，后者可用SKIP_COUNTER绕过或补录数据；若遭遇底层日志损坏，则需果断重置同步位点。以上就是MySQL主从同步Slave_IO和SQL线程为No问题的解决方法详细内容，更多关于MySQL优化与维护的资料请关注本站其它相关文章！