hadoop中edits文件損壞如何修復(fù)

這篇文章將為大家詳細(xì)講解有關(guān)hadoop中edits文件損壞如何修復(fù)，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

      前段時間公司hadoop集群宕機，發(fā)現(xiàn)是namenode 磁盤滿了。。清理出部分空間后，重啟集群時，重啟失敗。

又發(fā)現(xiàn)集群Secondary namenode 服務(wù)也恰恰壞掉，導(dǎo)致所有的操作log持續(xù)寫入edits.new 文件，等集群宕機的時候文件大小已經(jīng)達到了喪心病狂的70G+..重啟集群報錯 加載edits文件失敗。分析加載文件報錯原因是磁盤不足導(dǎo)致最后寫入的log只寫入一半就宕機了。由于log不完整，hadoop再次啟動加載edits文件時讀取文件報錯。由于edits.new 文件過大，存儲了好多操作log，所以必須要對其進行修復(fù)。

        嘗試刪除文件的最后幾行，結(jié)果還是報錯。于是查看源碼對edits 文件結(jié)構(gòu)進行分析發(fā)現(xiàn)是二進制格式，首行為版本號，然后是hadoop運行過程中的log記錄內(nèi)容，由操作碼 +長度(非必須)+其他項組成。

edits文件格式分析圖

解決辦法

報錯位置在源碼中的方法為org.apache.hadoop.hdfs.server.namenode.FSEditLog.loadFSEdits(EditLogInputStream edits)方法中讀取文件最后位置時因為缺少部分?jǐn)?shù)據(jù)報錯， 所以把這部分代碼單獨拿出來，去掉業(yè)務(wù)操作部分，只留讀取過程，記錄異常之前的文件長度len，然后將0到len 這部分的內(nèi)容復(fù)制出來成新的edits文件。啟動hadoop集群，成功！

NameNode啟動加載元數(shù)據(jù)情景分析

• NameNode函數(shù)里調(diào)用FSNamesystemm讀取dfs.namenode.name.dir和dfs.namenode.edits.dir構(gòu)建FSDirectory。

• FSImage類recoverTransitionRead和saveNameSpace分別實現(xiàn)了元數(shù)據(jù)的檢查、加載、內(nèi)存合并和元數(shù)據(jù)的持久化存儲。

• saveNameSpace將元數(shù)據(jù)寫入到磁盤，具體操作步驟：首先將current目錄重命名為lastcheckpoint.tmp;然后在創(chuàng)建新的current目錄，并保存文件；最后將lastcheckpoint.tmp重命名為privios.checkpoint.

• checkPoint的過程：Secondary NameNode會通知nameNode產(chǎn)生一個edit log文件edits.new，之后所有的日志操作寫入到edits.new文件中。接下來Secondary NameNode會從namenode下載fsimage和edits文件，進行合并產(chǎn)生新的fsimage.ckpt;然后Secondary會將fsimage.ckpt文件上傳到namenode。最后namenode會重命名fsimage.ckpt為fsimage，edtis.new為edits；

    PS：

最新的CDH版本的hadoop 集群啟動可以對edits文件進行recover操作，跳過報錯log

關(guān)于“hadoop中edits文件損壞如何修復(fù)”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。