记录一次生产环境MySQL突然变慢事故

记录一次生产环境MySQL突然变慢导致系统崩溃的经历

1、事情经过
因为公司阿里云服务器忘记续费（已经处理相关人员）导致整个装有MySQL数据的服务器服务停止，导致生产环境直接崩溃，可能有人会好奇为什么没有从库，因为项目新上，我刚接手整个项目才几天，也就是说我刚到公司负责公司项目才几天就出这事。

2、处理过程
本来想着快速启动了数据库以及相关的一些程序服务，就完全OK了，但是接下来发生的事情让我搞了差不多10天时间。我重启完程序服务后，生产环境突然变的异常的卡，其实项目的并发量并不是特别的大，每秒有差不多300吧，但是就是这样都会因为某一个线程的查询卡住导致其他MySQL线程的等待，查看MySQL的线程执行情况发现大量的“sending data”状态的线程，查阅网络资料发现说是慢查询。但是之前是不会出现这样的情况的，然后就是漫长的问题排查过程，因为之前确实没遇到过相关的情况，导致一开始没头绪，开始想着把卡在sending data状态的慢SQL拿出来先优化，之前的SQL确实写的很烂，优化完之后有所好转，非高峰期系统能正常使用，但是一到高峰期又开始卡。然后开始考虑做表分区（这些都是半夜熬夜搞的），做完表分区略微有所好转，所以有开始删除一些旧数据（已经失效的客户数据），因为其实数据量并不大，所以最开始我就排除了数据量太大的问题，但是到后面没办法了只能删数据看看有没有效果。删完还是没效果，一到高峰期卡。后面开始想是不是数据库配置问题，最开始已经排查过MySQL的配置文件，没发现什么问题，然后就考虑是不是因为某些配置是使用SQL命令来配置的，导致数据库服务重启而失效了，但是一下又没办法判断是哪些配置，搞到周末了去图书馆借了MySQL配置优化的书籍，最后定位到一个关键配置table_open_cache，查看配置的是400（show variables like ‘%table_open_cache%’;），这个配置按照书上的描述就是针对每个线程打开表的缓存，这样就不需要每次查询的时候都去打开文件，这样可以提高查询效率，这个打开表的数量跟MySQL的链接数量以及SQL语句中关联表的数量，因为当前系统存在很多复杂的SQL查询语句每条关联至少是7、8个表，那就算是有300个链接，那打开表的数量也就达到了300 * 8 的数量400是远远不够的，然后我查询数据库打开表的数量（show global status like ‘open%tables%’;）里面有2个参数Open_tables ，Opened_tables 两个参数都非常的大，第一个达到4千多，第二个忘记多少了，就说明MySQL频繁的去打开表，但是表缓存有配置的比较低，就导致查询很慢，于是修改这个参数为 6 * 1024，这个根据自己系统具体需求来修改，保存后发现系统流畅了，当时整个公司的激动了。当然期间还做过升级CPU的操作，因为MySQL查询线程卡住导致CPU一直高频运行一直报警。后来总结就是这样的配置用SQL命令来做真的很致命，因为根本就不知道是哪个环节出了问题，没有经验，还有就是从库真的非常重要，主库崩溃从库还可以继续运行这个很重要。
3、还有后续
因为看到服务器内存有点不够了，所以打算升级内存，升级内存需要重启服务器，所以又是12点后才开始操作的，升级完后我把MySQL的缓存池增加到了32G（升级到了64G内存），然后按照往常操作重启MySQL服务，但是发现重启不了，心想又出什么幺蛾子，查看MySQL的启动日志，发现如下错误“[ERROR] InnoDB: The innodb_system data file ‘ibdata1’ must be writable”，看着像是说这个数据文件没有写入的权限，百度一下发现好像很多遇到这样情况的，说是给权限就OK了，但是我没动过这个目录的权限呀，想着是不是因为升级了服务器配置有什么影响，就按照网友提供的方法修改权限，这个命令我就不写了，修改后重启还是报这个错，当时又懵逼了，又开始了各种百度，发现全部都是说修改权限（现在普遍网上的博文都是复制粘贴，这个很恶心），最后还是在一篇国外的博客上找到了解决方法现在贴出来给遇到一样情况的网友提供解决方案
1、请将以下两行添加到/etc/apparmor.d/local/usr.sbin.mysqld：
/data/ r,
/data/** rwk,
2、然后重新加载AppArmor配置文件：
sudo service apparmor reload
/data/指的是MySQL的数据存放目录
AppArmor是啥我也是第一次听后来查看mysql官网的解释说是Ubuntu系统自带的安全系统，但是我的是阿里云的centos我也不知道为什么有这个东西，具体他们有什么关系可以参考这个官网文章：https://blogs.oracle.com/jsmyth/apparmor-and-mysql
如果没有AppArmor这个东西大家还可以参考这个去修改：

“但是如果说AppArmor这个安全组件在centOS里没有找到，所以联想到centOS会不会有类似的安全控制器，后来发现AppArmor这个玩意就是简化版的SELinux，然后我突然意识到我应该怎么做。
setenforce 0（1为强制模式enforcing，0为宽容模式permissive）
其实还有一个模式disabled，但是只能在配置文件中改
编辑/etc/selinux/config，设置SELINUX=permissive（宽容模式）
然后再次启动mysql，万事大吉”

上面是在另外一篇博客中找到的，因为我只记录了解决方案，没记录地址所以只能贴出内容了。
4、总结
这就是这次事故的全部经过，一共花了8天才解决，也是因为自己没经验导致处理这么久，主要也还是之前的系统维护人员留下的坑太大了，在这期间我还迁移过数据库，就差点重装MySQL了。但是涉及到生产数据库，一切都非常的谨慎小心，而且白天不能操作，只能晚上处理。白天我就是查资料，然后杀MySQL卡住的线程，😶因为几个卡住的线程就会导致系统卡住，所以我就不停的在杀线程。记录下这次事故也是希望有类似经历的朋友能少走弯路，还有就是千万不要用SQL命令配置数据库，就算是配置了请记得做好记录备份，给后来人留下记录，毕竟都是同行。码字不容易如果帮到你们麻烦收藏关注下，哈哈