乍一看紅的不少挺嚇人，但仔細(xì)查看會發(fā)現(xiàn)，其實(shí)所有的報錯都指向同一處，node11節(jié)點(diǎn)。嘗試登錄無果，ping對應(yīng)IP無反應(yīng)。

這種情況下，基本斷定node11服務(wù)器異常宕掉了。本著老鳥的敏覺性，檢查hdfs可用性及數(shù)據(jù)塊，不過也不用過分擔(dān)心，畢竟咱是大數(shù)據(jù)平臺，掛一臺服務(wù)器不影響整體可用性。檢查確認(rèn)所有hdfs數(shù)據(jù)塊顯示均為健康狀態(tài)，也意味著后臺數(shù)據(jù)并未受到任何影響，管理節(jié)點(diǎn)也已從node11節(jié)點(diǎn)成功漂移。

雖說只是測試環(huán)境，但畢竟是機(jī)器掛掉了，本著閉環(huán)服務(wù)思維，還是需要快速恢復(fù)的。說時遲，那時快，那時不如這時快，迅速掏出手機(jī)聯(lián)系主機(jī)側(cè)重啟服務(wù)器。服務(wù)器起來后迅速登錄，習(xí)慣性df一把，發(fā)現(xiàn)根目錄使用率100%。檢查使用詳情，發(fā)現(xiàn)某個測試應(yīng)用程序跑飛了，又沒人看（測試環(huán)境都是這命?。Y(jié)果打了幾百G的日志。二話不說直接聯(lián)系應(yīng)用側(cè)詢問是否可以直接清理，得到確認(rèn)后，予以清理。

問題定位解決，雖然是大數(shù)據(jù)平臺，但是宕掉的機(jī)器服務(wù)還是需要恢復(fù)的，不然禁不起再垮一輪?；謴?fù)node11各個服務(wù)后，平臺恢復(fù)正常。但只是眨了一下眼，journalnode的綠色一閃而過，過后還是紅色依舊。

快速登錄服務(wù)器檢查journalnode日志，發(fā)現(xiàn)node11的journalnode服務(wù)有問題，一直在報錯檢測到valid length，進(jìn)入journalnode的數(shù)據(jù)目錄，查看journalnode的edits時間，發(fā)現(xiàn)最新的并不是當(dāng)前時間，與另外兩個journalnode時間不一致，且一直不刷新。

綜前分析，此前的根目錄滿導(dǎo)致node11節(jié)點(diǎn)最新的edits文件已經(jīng)無法正常寫入，進(jìn)而導(dǎo)致journalnode服務(wù)重啟，journalnode服務(wù)重啟后無法與另外的journalnode正常同步。

好在我們的journalnode有少數(shù)服從多數(shù)機(jī)制，停止有問題的node11節(jié)點(diǎn)的journalnode服務(wù)，直接mv掉node11節(jié)點(diǎn)的所有edits文件（注意只移走edits開頭文件，VERSION等其他信息需要保留，這可是身份信息，處理不當(dāng)會導(dǎo)致同步edits失?。?，然后再次啟動journalnode服務(wù)，發(fā)現(xiàn)node11已經(jīng)可以與其他兩個節(jié)點(diǎn)正常同步了。

本次的故障解決完成，后續(xù)會繼續(xù)給大家?guī)黻P(guān)于大數(shù)據(jù)平臺用到的相關(guān)組件的運(yùn)維分享，敬請期待。