最近幾次比較鬱悶，碰到幾起伺服器硬體故障或者存儲故障，直接導致伺服器系統夯住，MySQL服務或多或少受到影響，有的影響是MySQL服務自動重啟，有的影響是整個Linux系統重啟的，這種硬體錯誤發生在6的系統居多。通常我們以為MySQL服務使用了高可用架構，類似於MMM/MHA這種能實現故障轉移的架構 ...
最近幾次比較鬱悶，碰到幾起伺服器硬體故障或者存儲故障，直接導致伺服器系統夯住，MySQL服務或多或少受到影響，有的影響是MySQL服務自動重啟，有的影響是整個Linux系統重啟的，這種硬體錯誤發生在6的系統居多。通常我們以為MySQL服務使用了高可用架構，類似於MMM/MHA這種能實現故障轉移的架構，服務就能高枕無憂，可是最近發生的實事讓我對高可用有了新的認識。
案例一：DAS存儲碎文件過多，導致文件系統夯住，MySQL服務自動重啟。線上一個重要的業務線集群使用了MMM架構，其中master2使用了流式物理備份並二次壓縮的方式進行物理備份，本地備份完後會在凌晨將備份文件傳輸到遠端存儲，這個DAS存儲以NFS的方式掛載在伺服器上，其實存儲本身是一個windows的界面，夜裡進行傳輸備份的時候會發生master2的MySQL服務自動重啟，發生的頻率大概是兩個月一次，尤其是存儲的可用空間不到4T的時候，由於禁用了同步線程自動重啟，夜裡還需要人工操作並確認各服務正常。最初懷疑是系統的原因，6系統部分內核出現過文件系統夯死，MySQL服務假死不能提供應用的現象，後來存儲空間不夠，更換了存儲為GFS，連續觀察了幾天，從MMM的日誌和系統日誌都沒有再看到錯誤輸出信息（DAS存儲的時候每天會輸出一定的MMM錯誤日誌）。解決這類外部因素要保證DAS存儲碎文件或目錄不宜過多，或者有條件可以更換質量更好的存儲。
案例二：伺服器記憶體錯誤，導致master1伺服器文件系統夯住，集群MMM服務的agent與server不能正常通信，故障轉移功能無法進行。伺服器記憶體錯誤導致系統夯住，這種類型的錯誤導致夯機的危害相比上面案例更大，上面的錯誤MySQL服務可以自動重啟後繼續提供應用連接，而記憶體錯誤會造成MMM/MHA這種通過SSH方式進行通信和維護心跳機制的架構，容易出現進程類似sleep的現象，不僅故障無法自動轉移，也會出現手動切換失敗的可能（文件系統夯住導致MMM命令無法使用，長時間不能出來結果）。解決這類文件辦法只能是重啟硬體故障的伺服器才能釋放僵死的進程，MMM命令才能正常使用，臨時解決這個期間問題的辦法是手動添加應用連接的VIP到master2，保證服務受到最小的影響。但是要註意腦裂，伺服器恢復正常後，重啟MMM的monitor和agent服務前，要刪除手動添加的VIP併進行一次arping廣播。
