mysql job failed to start-tomcat问题变种

Posted 2021-01-07 熊继明

首先说一说问题的背景：

服务器端采用tomcat为J2EE容器，在一次失败的NIO测试（把控制台输出信息写在了NIO阻塞用的循环中）后，Ubuntu系统几乎崩溃，关闭java相关进城后，tomcat无法再次启动，我就采取了互联网人民最厉害的招数-重启服务器。
在重启服务器之后，tomcat可以启动，但是获取不到JDBC连接了，显而易见，这是mysql没启动，正当我准备开启MySQL服务的时候，出现了下面的显示
：

在种种排查之后，就像端口占用、相关配置文件，在通过文件启动MySQL服务的时候，报错信息变得清晰了

通过查看，所说目录的大小并不像ERROR中说的那样，再次查看Ubuntu的硬盘容量，发现占用率几乎到了100%：

在网上找了很多方法之后，我也觉得只有日志文件才会发生在短时间内增大的可能，于是准备删除与MySQL相关的日志文件（狠下心直接删除了整个/var/log）：

可以看到，我们的问题还是没有解决，那么问题到底出在了哪里？

---

回忆问题发生的整个过程，源头是在J2EE项目一段错误的代码，雅思托福怎么考会不会是tomcat产生的日志文件突然增大以至于占满了整个Ubuntu硬盘：来吧，删除

至此我们删除了和今天有关的所有tomcat日志文件（其实是没必要的，但是由于没有什么必须数据），同时也手动清空了catalina.out中的所有内容，至此 我们又查看硬盘容量情况，尝试再次启动MySQL服务：

至此，问题解决了，MySQL在检查日志文件预留空间时，会因为整个磁盘的大小而被限制，而报错的时候不可能精确的找出是哪里出了问题，毕竟万一是你自己真的把空间用完了呢。报错虽然是MySQL给的，但是tomcat才是真正的幕后凶手。

---

通过这次报错，我们可以发现，有时错误产生的结果并不是真正的原因，但是其中必定存在着种种联系，学会透过现象看本质才是真的解决方案，同时，学英语还是有用的。至少你能看懂报错信息。

---

解决方案：对于NIO的难以控制，业界有目共睹，所以果断转行Netty取而代之，对于tomcat日志文件的无限增长，我们可以通过检测，在日志文件异常时通过dump或终止服务器输出来防止空间利用率接近100%