硬件錯誤系統夯住高可用沒法自動故障轉移案例分享

　　最近幾回比較鬱悶，碰到幾起服務器硬件故障或者存儲故障，直接致使服務器系統夯住，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廣播。