记一次mysql服务的流血事件

2018年5月10日，使用django在服务器上搭建了一个web站点，遇到了一系列的问题，最终在官网找到了解决方案，然而晚上十点左右无意间发现mysql服务处于挂掉状态，网站和微信小程序全部不能正常使用，第一想到的是cron脚本，因为之前mysql服务就经常会自动停止服务，后来干脆写了个cron脚本实时监听mysql服务并自动重启mysql，查看cron日志发现，mysql于10号上午就已经开始停止服务，期间cron脚本有自动重启mysql，前面几次都能正常重启，但是后面mysql持续多次自动停止服务，cron监听到mysql挂掉并尝试了重启mysql，但是一直没有重启成功，截取部分cron监听mysql日志文件如下：

于是手动重启mysql，直接报如下错误：

Starting MySQL.. ERROR! The server quit without updating PID file (/var/lib/mysql/iZm5eiqn00z9x3zuxajldvZ.pid)

提示某pid文件不存在，到目录下查看确实是没有该pid文件，网上大多数说是由于目录下没有相关权限，于是按照操作给定相关权限，并新建了相关pid文件，写入了新的pid，重启mysql，提示success，以为成功了，结果再查看mysql状态，依然是挂掉状态，再次重启，再次报同样的错误，我仔细想了下应该不是这个权限相关的问题，因为我这个毕竟不是首次安装mysql，mysql服务已经运行有快两年的时间了，要是权限的问题的话那之前就不可能好使，所以权限的问题基本排除。

再看到有说法是ib_logfile日志文件的问题，于是先把ib_logfile文件备份后再做删除处理（注意在做删除操作之前一定要做好备份处理，本文的主要目的就是强调备份的重要性），删除之后重启mysql，结果还是不行，干脆reboot重启了服务器，重启机器后mysql竟然起来了，难道真的是ib_logfile文件的原因。进入mysql，show databases、show tables，一切看起来都正常，但是使用select的时候竟然提示表不存在。经过一番搜索大概明白了是因为ibdata1文件的原因，这个文件是InnoDb存储引擎相关的文件，简单的说mysql数据都存在了这个文件里，现在被删除了，自然会被提示表不存在了，那把刚刚备份的ibdata1文件粘贴过来不就行了？ 可惜尝试无果，原因尚未搞明白，有兴趣的可以自行去详细了解下。既然不能直接恢复，那就把整个备份的数据库重新导入总应该可以吧，ok，服务器前段时间刚好配置了个cron定时任务来专门备份mysql数据的，这次总算是派上用场了，drop database xxxx，报错，别管那么多，直接到mysql目录下 rm -rf xxxx，success删除数据库成功，重新导入备份数据库，success导入数据库成功，success select数据库成功，至此mysql已经恢复正常，不过丢失了未备份期间的少部分数据， 强调一点，最好的情况是永远不要用上备份文件，最坏的情况是没有备份文件可用。

此次mysql事件起因尚不明确，十有八九是云服务器低配置的原因，据很多人反应低配置的云服务器经常会有mysql服务自动终止的情况，不管怎样，在费了九牛二之力后，mysql总算被抢救回来了，只强调一点，数据备份异常重要，不然所有的努力都可能功亏一篑。数据备份！！！

对了，最后附上小程序一张说一万次我爱你的图片

欢迎交流, 欢迎关注.