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