記一次故障處理----主機異常關閉後mongodb二進位檔案損壞

標籤：查詢   error   準備   驗證   關閉   進位   模式   out   erro   

今天,在某個示範環境中,我們的產品經曆過整個機房斷電後,出現了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檔案系統很穩定,經曆過這次事之後,發現原來之前的都是誤解,穩定只是一個相對的概念.

記一次故障處理----主機異常關閉後mongodb二進位檔案損壞