MySQL报错ER_RPL_SLAVE_IO_THREAD_KILLED，远程帮忙修复故障过程分享

开始）

那天下午，我正在工位上摸鱼，想着晚上吃啥，突然手机开始嗡嗡作响，一连串的报警短信像催命符一样跳出来，抓过手机一看，核心数据库的一台从库服务器亮起了红灯，报警信息很明确：“Fatal error: The slave I/O thread was killed, Error_code: ER_RPL_SLAVE_IO_THREAD_KILLED”，心里咯噔一下，这意味着主从同步断了，主库的数据无法同步到这台从库上，时间一长，万一主库出问题,业务就得停摆。

我赶紧放下手里的零食，打开电脑连上VPN，直奔那台出问题的从库服务器，首先得看看现场情况，打开了MySQL的命令行，输入了那个熟悉的命令 SHOW SLAVE STATUS\G，刷出来一大片信息，我快速扫瞄关键字段，果然，Slave_IO_Running 显示为 No，而 Slave_SQL_Running 还显示为 Yes，这就印证了报警，是负责从主库拉取日志的I/O线程挂了，而负责执行日志的SQL线程还在傻傻地等着，在 Last_IO_Error 字段里，清晰地记录着错误信息：“The slave I/O thread was killed during a event read from the master”，根据MySQL官方文档的描述，这个错误通常意味着Slave的I/O线程在从Master读取二进制日志事件时被意外终止了。

光知道线程被杀还不行，得搞清楚为啥被杀，这种问题，原因可能五花八门，我定了定神，开始按经验一个个排查，首先怀疑的是网络问题，是不是从库和主库之间网络闪断了？我立刻用 ping 命令测试了一下主库的IP，延迟很正常，也没有丢包，又不放心，用 telnet 测试了主库的MySQL端口（默认3306），也是通的，看来网络暂时是正常的,但这不能排除之前有过短暂的网络波动。

我查看了从库的错误日志文件（通常叫 hostname.err），围着报警发生的时间点仔细翻看，错误日志里除了记录下ER_RPL_SLAVE_IO_THREAD_KILLED这个错误外，并没有其他更详细的线索，看来得把目光转向主库，我联系了负责主库的同事，让他帮忙检查一下主库在那个时间点有没有什么异常操作，比如是否不小心重启了，或者有没有执行什么大的事务，同事反馈说主库一直很稳定，没有重启记录,业务也正常。

排除了外部因素，问题可能出在从库本身，我琢磨着，是不是服务器资源不足导致的？比如内存爆了，OOM Killer（内存溢出杀手）把I/O进程给干掉了？我赶紧用 free -h 看了下内存使用情况，剩余内存还挺充裕，再用 top 命令看CPU和负载，也都非常低,这就奇怪了。

既然常规路子找不到原因，我决定尝试重启一下I/O线程，有时候一些临时性的小毛病重启就能好，在MySQL命令行里，我先执行了 STOP SLAVE IO_THREAD;，然后再执行 START SLAVE IO_THREAD;，执行完后，马上再次查看 SHOW SLAVE STATUS，心凉了半截，Slave_IO_Running 刚起来几秒钟，又变成了 No,错误信息一模一样。

这下问题有点棘手了，重启大法失效，说明有更深层次的原因，我静下心来，再次仔细审视 SHOW SLAVE STATUS 的输出，不放过任何一个字段，突然，我注意到 Master_Log_File 和 Read_Master_Log_Pos 这两个值已经很久没有变化了，而主库的二进制日志早就滚动了好几个新文件了，我意识到，可能是在读取某个特定的二进制日志事件时卡住了，然后超时或被终止，会不会是那个日志事件本身有问题？或者从库的中间件（比如代理或防火墙）拦截了长时间的连接？

抱着试试看的心态，我决定跳过当前这个可能“有问题”的二进制日志文件，让从库从主库下一个新的日志文件开始读取，这样做有点风险，意味着我会丢失当前这个日志文件里尚未同步的数据，但考虑到业务容忍度以及从库的备用性质，可以接受，我先在主库上执行 SHOW MASTER STATUS;，记下最新的二进制日志文件名和位置点，然后回到从库,执行了以下命令序列：

STOP SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='最新文件名', MASTER_LOG_POS=最新位置点;
START SLAVE;

执行完 START SLAVE 后，我的心悬了起来，紧紧盯着 SHOW SLAVE STATUS 的输出，几秒钟后，Slave_IO_Running 和 Slave_SQL_Running 都变成了 Yes，Seconds_Behind_Master（落后主库的秒数）开始逐渐减少，成功了！从库重新开始顺畅地从主库同步数据了。

长舒一口气后，我并没有立刻离开，我得弄清楚根本原因，防止下次再发生，我对比了跳过的那个二进制日志文件和前后文件的大小，发现那个文件的大小异常地大，让主库的同事帮忙解析了一下那个文件的内容，发现里面包含了一个超大的事务，是某个开发人员误操作导致的一次性全表更新，很可能就是这个长时间传输的大事务，导致从库的I/O线程在读取过程中超过了某个超时时间，最终被MySQL内部机制给“杀”掉了，后来，我们也对开发流程做了提醒,避免再出现这种可能影响复制的大事务。

至此，这场由ER_RPL_SLAVE_IO_THREAD_KILLED报错引发的故障算是彻底解决了，总结下来，关键还是耐心查看状态信息，由简到繁地排查网络、资源、日志本身等问题，有时候需要一点经验和胆量去尝试跳过有问题的点。 结束）