mysql 数据同步 出现Slave_IO_Running:No问题的解决方法小结

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上的数据。

转自:http://www.jb51.net/article/27220.htm

  • 1
    点赞
  • 32
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
MySQL 主从复制是一种非常重要且常用的数据同步方式,对于数据库管理员来说,保证主从同步的正常运行对于数据库的可靠性和稳定性都是非常重要的。当我们在使用 MySQL 主从同步时,如果发现 slave_io_running:no 的情况,那么意味着 MySQL 从服务器的 IO 线程停止了工作。 IO 线程是 MySQL 主从复制中非常重要的一个组件,它的作用是从主服务器上读取二进制数据,并将其传输到从服务器上。如果 IO 线程出现问题,那么意味着从服务器无法从主服务器获取新的数据,从而导致从服务器无法同步主服务器的数据。 在出现 slave_io_running:no 的情况时,我们需要立即查找 IO 线程出现问题的原因,并进行解决。以下是常见的 IO 线程故障原因及对应解决方案: 1. 网络问题。如果主服务器和从服务器之间的网络出现问题,那么 IO 线程就无法正常工作。我们可以通过检查网络连接以及网络质量来解决这个问题。 2. DNS 解析错误。如果主服务器和从服务器之间使用的是主机名进行通信,那么可能出现 DNS 解析错误的情况。我们需要检查主机名是否正确,以及 DNS 解析是否正常。 3. 权限问题。如果从服务器的用户权限不正确,那么也可能会导致 IO 线程无法正常工作。我们需要检查从服务器的用户权限是否足够,以及是否正确配置了主从服务器之间的连接信息。 4. 数据库配置问题。如果从服务器的数据库配置不正确,那么也可能会导致 IO 线程无法正常工作。我们需要检查从服务器的数据库配置是否正确,并根据需要进行更改。 总的来说,当出现 slave_io_running:no 的情况时,我们需要立即对问题进行排查和解决,以便尽快恢复 MySQL 主从同步的正常运行。在排查问题过程中,我们需要充分了解 MySQL 主从复制的工作原理,熟悉常见的故障原因,并加强对 MySQL 数据库的日常维护和管理工作,以提高数据库的可靠性和稳定性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值