記一次故障處理----主機異常關閉後mongodb二進制文件損壞

今天,在某個演示環境中,咱們的產品經歷過整個機房斷電後,出現了mongodb二進制文件損壞,如下是故障的分析記錄過程:

1.在客戶處支撐的同事發現整個機房斷電再恢復後,3個mongodb複製集中,有1個主機上的mongodb服務狀態報錯

2.登陸後臺發現複製集中每一個mongodb主機上,mongod進程都在

3.在服務狀態好着的mongodb主機上,經過mongo登陸數據庫,查詢複製集狀態,發現複製集狀態正常,1個primary+2個secondary,而且optimeDate時間一致.

這個時候我就很好奇了,按說mongodb複製集狀態都正常着,不至於再出現其中1個節點上查詢mongodb服務狀態報錯的狀況了.

登陸報錯的主機上,經過mongo登陸數據庫,這時候,很詭異的事來了,終端上直接報錯:"Bus error",很奇怪啊,我這仍是第一次遇到mongo命令報這個錯.感受本身是否是遇到什麼詭異事件了.而後執行mongo --version,同樣的報錯"Bus error".

這個時候,不知道怎麼的,就突然想起好久遠時候的一個靈異事件了----最初作產品的兄弟遇到了這樣一個問題:同一個mongodb rpm包,安裝好以後,在某個主機上安裝的mongod的二進制文件的md5和預期的不同了.

而後就使用md5sum 去算這個提示"Bus error"的mongo,結果終端上直接報錯"Input/Output error"了,可是使用md5sum去算同目錄下另外幾個mongodb相關的文件就沒報錯.

到這個時候,我意識到操做系統可能出了啥故障了.喊了操做系統組的同事看了下,----剛開始還覺得是隻有mongo這個二進制文件被人或者其餘服務給修改了,可是,在咱們準備把這個損壞的mongo二進制文件備份到另一個目錄的時候,終端上繼續報錯了"cp *** Input/Output error".

至此,操做系統組的同事肯定:可能由於機房斷電,主機操做系統中出現文件系統損壞了.

爲了驗證這個猜想,接下來,咱們重啓了服務器(好在這個時候還沒上業務),而後從新啓動過程當中,提示信息中果真有根分區和另一塊分區的文件系統損壞的提示.按照提示信息進入了維護模式,使用fsck -y /dev/分區名 修復以後,再正常啓動,操做系統就再也不報錯了.

最後,經過重裝mongodb的rpm包,將mongodb的二進制文件報錯處理掉了.至此,mongodb二進制文件損壞問題修復完成.

我以前一直覺得linux文件系統很穩定,經歷過此次事以後,發現原來以前的都是誤解,穩定只是一個相對的概念.