mysql job failed to start-tomcat問題變種

首先說一說問題的背景：

服務器端採用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%