mysql 数据同步 出现Slave_IO_Running:No问题的解决方法小结
更新时间：2011年05月25日 17:47:13 作者：
mysql replication 中slave机器上有两个关键的进程，死一个都不行，一个是slave_sql_running，一个是Slave_IO_Running，一个负责与主机的io通信，一个负责自己的slave mysql进程。
下面写一下，这两个要是有no了，怎么恢复。。
如果是slave_io_running no了，那么就我个人看有三种情况，一个是网络有问题，连接不上，像有一次我用虚拟机搭建replication，使用了nat的网络结构，就是死都连不上，第二个是有可能my.cnf有问题，配置文件怎么写就不说了，网上太多了，最后一个是授权的问题，replication slave和file权限是必须的。如果不怕死就all咯。。
一旦io为no了先看err日志，看看爆什么错，很可能是网络，也有可能是包太大收不了，这个时候主备上改max_allowed_packet这个参数。
如果是slave_sql_running no了，那么也有两种可能，一种是slave机器上这个表中出现了其他的写操作，就是程序写了，这个是会有问题的，今天我想重现，但是有时候会有问题，有时候就没有问题，现在还不是太明了，后面再更新，还有一种占绝大多数可能的是slave进程重启，事务回滚造成的，这也是mysql的一种自我保护的措施，像关键时候只读一样。
这个时候想恢复的话，只要停掉slave，set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;再开一下slave就可以了，这个全局变量赋值为N的意思是：
This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.
This statement is valid only when the slave thread is not running. Otherwise, it produces an error.
呵呵，讲的比我清楚。
MYSQL镜像服务器因错误停止的恢复
下午主服务器，由于一些原因，导致死机，重启后，发现从服务器的数据没有跟上。
配好MYSQL主从也才前几天的事，没多少经验，第一次碰上这问题，有点焦急。不过，自己试了下，还算解决了：）
从服务器上
Master_Log_File: mysqlhxmaster.000007
Read_Master_Log_Pos: 84285377
看一下主服务器：mysqlhxmaster.000007 | 84450528 |
已经过后很多了，确实没跟上。
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
有问题了，Slave_SQL_Running应该是Yes才对。
再往下看，有错误的提示：
Last_Errno: 1053
Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: 'INSERT INTO hx_stat_record ......(一句SQL语句)'
这里有说明要怎么操作了：）
先stop slave，然后执行了一下提示的语句，再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
OK了，从服务器也在几分钟内把堆积的log处理完了，两边又同步了：)
从MYSQL服务器Slave_IO_Running: No的解决2
早晨机房意外断电，导致了发现mysql从服务器同步异常。使用以前碰到的Slave_SQL_Running为No的解决办法无效，仍然无法同步。
查看一下状态show slave status
Master_Log_File: mysqlmaster.000079
Read_Master_Log_Pos: 183913228
Relay_Log_File: hx-relay-bin.002934
Relay_Log_Pos: 183913371
Relay_Master_Log_File: mysqlmaster.000079
Slave_IO_Running: No
Slave_SQL_Running: Yes
主服务器show master status\G
File: mysqlmaster.000080
Position: 13818288
Binlog_Do_DB:
Binlog_Ignore_DB: mysql,test
mysql错误日志：
100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log 'mysqlmaster.000079' at position 183913228, relay log './hx-relay-bin.002934' position: 183913371
100512 9:13:17 [Note] Slave I/O thread: connected to master 'replicuser@192.168.1.21:3306', replication started in log 'mysqlmaster.000079' at position 183913228
100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100512 9:13:17 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
100512 9:13:17 [Note] Slave I/O thread exiting, read up to log 'mysqlmaster.000079', position 183913228
这次是Slave_IO_Running为No，从日志上来看，服务器读mysqlmaster.000079这个Log的183913228这个位置时发生错误，这个位置不存在，于是无法同步。
查看一下这个Log的最后几行：
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
尝试从损坏之前的位置开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220;
SLAVE START;
无效！
只好从新的日志开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0;
SLAVE START;
此时Slave_IO_Running恢复为Yes，同步进行了！观察了会儿，没有任何出错迹象，问题解决。
另外，出现Slave_IO_Running:NO还有一个原因是slave上没有权限读master上的数据。
如果是slave_io_running no了，那么就我个人看有三种情况，一个是网络有问题，连接不上，像有一次我用虚拟机搭建replication，使用了nat的网络结构，就是死都连不上，第二个是有可能my.cnf有问题，配置文件怎么写就不说了，网上太多了，最后一个是授权的问题，replication slave和file权限是必须的。如果不怕死就all咯。。
一旦io为no了先看err日志，看看爆什么错，很可能是网络，也有可能是包太大收不了，这个时候主备上改max_allowed_packet这个参数。
如果是slave_sql_running no了，那么也有两种可能，一种是slave机器上这个表中出现了其他的写操作，就是程序写了，这个是会有问题的，今天我想重现，但是有时候会有问题，有时候就没有问题，现在还不是太明了，后面再更新，还有一种占绝大多数可能的是slave进程重启，事务回滚造成的，这也是mysql的一种自我保护的措施，像关键时候只读一样。
这个时候想恢复的话，只要停掉slave，set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;再开一下slave就可以了，这个全局变量赋值为N的意思是：
This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.
This statement is valid only when the slave thread is not running. Otherwise, it produces an error.
呵呵，讲的比我清楚。
MYSQL镜像服务器因错误停止的恢复
下午主服务器，由于一些原因，导致死机，重启后，发现从服务器的数据没有跟上。
配好MYSQL主从也才前几天的事，没多少经验，第一次碰上这问题，有点焦急。不过，自己试了下，还算解决了：）
从服务器上
Master_Log_File: mysqlhxmaster.000007
Read_Master_Log_Pos: 84285377
看一下主服务器：mysqlhxmaster.000007 | 84450528 |
已经过后很多了，确实没跟上。
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
有问题了，Slave_SQL_Running应该是Yes才对。
再往下看，有错误的提示：
Last_Errno: 1053
Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: 'INSERT INTO hx_stat_record ......(一句SQL语句)'
这里有说明要怎么操作了：）
先stop slave，然后执行了一下提示的语句，再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
OK了，从服务器也在几分钟内把堆积的log处理完了，两边又同步了：)
从MYSQL服务器Slave_IO_Running: No的解决2
早晨机房意外断电，导致了发现mysql从服务器同步异常。使用以前碰到的Slave_SQL_Running为No的解决办法无效，仍然无法同步。
查看一下状态show slave status
Master_Log_File: mysqlmaster.000079
Read_Master_Log_Pos: 183913228
Relay_Log_File: hx-relay-bin.002934
Relay_Log_Pos: 183913371
Relay_Master_Log_File: mysqlmaster.000079
Slave_IO_Running: No
Slave_SQL_Running: Yes
主服务器show master status\G
File: mysqlmaster.000080
Position: 13818288
Binlog_Do_DB:
Binlog_Ignore_DB: mysql,test
mysql错误日志：
100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log 'mysqlmaster.000079' at position 183913228, relay log './hx-relay-bin.002934' position: 183913371
100512 9:13:17 [Note] Slave I/O thread: connected to master 'replicuser@192.168.1.21:3306', replication started in log 'mysqlmaster.000079' at position 183913228
100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100512 9:13:17 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
100512 9:13:17 [Note] Slave I/O thread exiting, read up to log 'mysqlmaster.000079', position 183913228
这次是Slave_IO_Running为No，从日志上来看，服务器读mysqlmaster.000079这个Log的183913228这个位置时发生错误，这个位置不存在，于是无法同步。
查看一下这个Log的最后几行：
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
尝试从损坏之前的位置开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220;
SLAVE START;
无效！
只好从新的日志开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0;
SLAVE START;
此时Slave_IO_Running恢复为Yes，同步进行了！观察了会儿，没有任何出错迹象，问题解决。
另外，出现Slave_IO_Running:NO还有一个原因是slave上没有权限读master上的数据。
相关文章
MySQL是一种关系数据库管理系统，所使用的 SQL 语言是用于访问数据库的最常用的，本文主要以Mysql免安装版为例，帮助大家解决安装与配置mysql的步骤2021-06-06
数据库管理系统中,死锁是指多个事务互相等待对方释放资源,导致事务僵持不前,影响系统稳定性,本文详细介绍了如何在MySQL中排查和分析死锁问题,文中通过代码介绍的非常详细,需要的朋友可以参考下2024-09-09
这篇文章主要给大家介绍了关于MySQL中int最大值的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面来一起学习学习吧2019-02-02
以下是对Linux下MySQL数据库的备份与还原进行了详细的分析介绍。需要的朋友可以过来参考下2013-08-08
安装配置mysql及Navicat prenium的详细流程
这篇文章主要介绍了安装配置mysql及Navicat Premium的详细流程,配置方法也真的很简单，本文给大家详细介绍mysql Navicat Premium安装配置相关知识感兴趣的朋友，一起学习吧2021-06-06
对 MySQL 数据库的查询，除了基本的查询外，有时候需要对查询的结果集进行处理。例如只取 10 条数据、对查询结果进行排序或分组等等，今天就给大家分享MySQL一些常用高级SQL语句，感兴趣的朋友一起看看吧2021-07-07
二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句2011-10-10
本文讲述了在MySQL中识别和终止导致死锁的SQL语句,通过SHOWENGINEINNODBSTATUS和INFORMATION_SCHEMA表,可以找到死锁的具体事务,感兴趣的可以了解一下2024-11-11
在处理大规模数据时,数据库性能的优化变得尤为重要,MySQL提供了一种称为“分区”（Partitioning）的技术,可以显著提高查询效率和管理大型数据库表的能力,本文将详细介绍MySQL中的数据表分区技术,包括其基本概念、类型以及如何实现和维护,需要的朋友可以参考下2025-02-02
如何在Linux平台卸载MySQL呢？这篇文章主要介绍了Linux下卸载MySQL数据库的方法，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2017-06-06
最新评论