磁盘撑爆了

今天星期一，一上班就碰到两个问题，整理记录一下。

一、磁盘爆了

测试妹子在做功能测试的时候，发现服务端接口没有返回数据，后端技术兄弟登录测试环境去处理，重新执行了发布脚本然后发现应用无法启动，折腾了好一会儿没搞定，我本来不太想处理这种事的，一个原因是对于任何一个开发人员来讲，除了会写业务逻辑代码，也必须能够快速解决各种问题，他们需要在处理问题中成长，另外一原因我本来就懒，团队里别人能做的事我都尽量不去做，实在没有办法我才会介入具体技术问题的处理，但今天系统要发布，不想拖得太晚，下面是处理的步骤：

1、检查应用启动日志

发现有一个ScheduleJobService类启动报错，错误信息如下：

这是一套开源的Java定时任务管理框架，其他同事整合进来我一直没有关注（下次整理一下），第一个想法是这个怎么会报错，这次版本肯定没有改动这块相关的代码，然后不管3721，自己再重新执行发布脚本（常规操作，重启能解决80%的问题），然并卵照样报错，太不给面子了。

2、检查数据库

测试环境的数据库为了节省成本没有用云RDS，而是自己下载开源MySQL搭建的，怀疑是不是数据死锁了什么问题造成的(解决问题时要怀疑一切，而不是肯定这个不会造成那个不会造成)，执行了show processlist,发现两条SQL一直堵塞着。

将两条SQL KILL掉，开始没KILL掉，KILL了两次都KILL不掉，那就不客气了把MySQL重启一下，芭比Q了，MySQL启动不了，怀疑前段时间在整BinLog把BinLog索引文件折腾坏了，那就把mysql-bin.index删掉，再重启还是启动不了，然后看一下数据库日志，发现报/var/run/mysqld/mysqld.sock.lock无法创建，进入/var/run发现mysqld目录没了那就手工创建一下，然后启动MySQL就成功了。 

3、重新启动应用

数据库正常了，也没有阻塞的SQL了，我们再启动应用，很遗憾还是不给面子，发现又是SQL报错，这时候就开始怀疑是否磁盘满了，然后用df命令查一下磁盘100%，好吧，那就把一些日志删除掉，再重启就好了。

注：这里还增补了qrtz定时任务表的数据，解决数据不一致的问题造成无法启动，这个下下次再梳理。

4、检查磁盘占用情况

要清理磁盘，首先要找到哪些文件或目录占用空间比较大，这个可以切换到根目录下一层层执行du -h --max-depth=1，这个命令虽然很简单但其实很多没有做过运维的开发可能并不知道，并不是只有高深的知识才有价值，能解决实际问题的知识就是有价值的。

注：从我介入开始整个过程大约持续了1个小时，其实很不应该的，测试环境一般出现问题大概率是磁盘撑爆了，因为对于生产环境我们会去做日志归档，但测试环境一般都懒得去做，满了再处理一下就好，以前也有几次磁盘满了造成GitLab无法提交连接，这次因为受奇怪的日志误导造成折腾了1个小时。

废话那么多其实是为了凑字数，总结起来其实就是：

磁盘满->qrtz定时任务管理器 delete语句阻塞-> 定时任务管理器数据不一致->应用无法启动。