记一次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总算被抢救回来了,只强调一点,数据备份异常重要,不然所有的努力都可能功亏一篑。数据备份!!!

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

欢迎交流, 欢迎关注.

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180511G1COFH00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券