首先说一说问题的背景:
服务器端采用tomcat为J2EE容器,在一次失败的NIO测试(把控制台输出信息写在了NIO阻塞用的循环中)后,Ubuntu系统几乎崩溃,关闭java相关进城后,tomcat无法再次启动,我就采取了互联网人民最厉害的招数-重启服务器。
在重启服务器之后,tomcat可以启动,但是获取不到JDBC连接了,显而易见,这是MySQL没启动,正当我准备开启MySQL服务的时候,出现了下面的显示
:
在种种排查之后,就像端口占用、相关配置文件,在通过文件启动MySQL服务的时候,报错信息变得清晰了
通过查看,所说目录的大小并不像ERROR中说的那样,再次查看Ubuntu的硬盘容量,发现占用率几乎到了100%:
在网上找了很多方法之后,我也觉得只有日志文件才会发生在短时间内增大的可能,于是准备删除与MySQL相关的日志文件(狠下心直接删除了整个/var/log):
可以看到,我们的问题还是没有解决,那么问题到底出在了哪里?
回忆问题发生的整个过程,源头是在J2EE项目一段错误的代码,
至此我们删除了和今天有关的所有tomcat日志文件(其实是没必要的,但是由于没有什么必须数据),同时也手动清空了catalina.out中的所有内容,至此
我们又查看硬盘容量情况,尝试再次启动MySQL服务:
至此,问题解决了,MySQL在检查日志文件预留空间时,会因为整个磁盘的大小而被限制,而报错的时候不可能精确的找出是哪里出了问题,毕竟万一是你自己真的把空间用完了呢。报错虽然是MySQL给的,但是tomcat才是真正的幕后凶手。
通过这次报错,我们可以发现,有时错误产生的结果并不是真正的原因,但是其中必定存在着种种联系,学会透过现象看本质才是真的解决方案,同时,学英语还是有用的。至少你能看懂报错信息。
解决方案:对于NIO的难以控制,业界有目共睹,所以果断转行Netty取而代之,对于tomcat日志文件的无限增长,我们可以通过检测,在日志文件异常时通过dump或终止服务器输出来防止空间利用率接近100%