creat loader main sta 拷貝 最重要的 讀取 reat ber

背景：昨晚11點40幾分，終於各個集群組件都啟動成功了，然後心滿意足的去睡覺了，但是今早再起來再去啟動的時候就出現了namenode的問題，然後就開始了查找原因的艱辛歷程。

查看報錯的log日誌：

2019-04-07 13:22:57,746 WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Encountered exception loading fsimage
java.io.IOException: There appears to be a gap in the edit log. We expected txid 6, but got txid 10.

at org.apache.hadoop.hdfs.server.namenode.MetaRecoveryContext.editLogLoaderPrompt(MetaRecoveryContext.java:94)
at org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader.loadEditRecords(FSEditLogLoader.java:212)
at org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader.loadFSEdits(FSEditLogLoader.java:140)
at org.apache.hadoop.hdfs.server.namenode.FSImage.loadEdits(FSImage.java:835)
at org.apache.hadoop.hdfs.server.namenode.FSImage.loadFSImage(FSImage.java:690)
at org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:281)
at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1063)
at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:767)
at org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:609)
at org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:670)
at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:838)
at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:817)
at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1538)
at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1606)

我把問題復制去網上搜，大多都是讓修復：

原因：namenode元數據被破壞，需要修復
解決：恢復一下namenode

hadoop namenode -recover

我是第一次搭建集群所以沒有數據丟失的風險，所以就執行了但是，在修復中還是報錯了。

最終找到以下這篇文章，解決了我的問題非常感謝：以下是摘抄了幾個重點

解決方法：這裏基本上看不懂，跳過吧

namenode在啟動的過程中，最重要的一個動作就是拼湊集群的元數據，有哪些文件和目錄，分別存放在哪裏等信息。這個重要的過程分兩步：

（1） 讀取fsimage和edits數據，拼湊出元數據。註意，這裏的元數據是指，有哪些目錄和文件，每個文件有多大這樣的信息。

（2） 獲取每個datanode的匯報信息，整合出完整的blockMap。這裏就還包括文件和實際存儲的映射關系，一個文件具體存放在那個節點。

以下是對日誌的分析

查看日誌中的報錯信息，可以明顯地看到，這個問題是發生在FSEditLogLoader.loadFSEdits這個方法中，也就是在獲取edits文件時報錯。這裏要註意的一點是，在配置有ha的hadoop2.0集群中，namenode啟動時的fsimage是直接從本地獲取，而edits是從journalnode上獲取的。 所以 “There appears to be a gap in the edit log. We expected txid 6, but got txid 10.. ” 這個問題肯定是發生在journalnode上，而不是namenode上的。（讀懂這裏基本上就知道原理，讀不懂也沒關系，繼續往下看），英文的意思是日誌有空白，我們期望得到txid為6，得到的確是10 。

網上有一種解決方法，說是把active namenode上的name文件夾拷貝到standby namenode上。我試了，而且拷貝過來的name目錄中也有176531929這條Edits數據，但啟動namenode時還是報同樣的錯，說找不到176531929這條edit數據。說明這個方法不可行！ 因為Edits是要在啟動時去journalnode上讀取的。這個問題的根本原因是你的journalnode上存在Edits數據丟失的情況。這一句看懂就基本上找到原因了，也有方向了，在HA的解讀中就有說明，

所以我去查看我的journalnode目錄，果然發現journalnode/yarncluster/current下面沒有176531929這一條Edits數據。所以，這就是這個錯誤出現的根本原因。然後解決辦法很簡單，從active namenode上拷貝這條Edits數據到所有journalnode中。重新啟動，問題解決，沒有數據丟失，也不需要recovery。

以上的藍色字體都是摘抄別人博客，黑色和紅色是自己的標記和理解。

我根據我自身的錯誤“我們期望得到txid為6，得到的確是10 。”去active的nn裏找到txid文件，將其復制上傳到無法啟動nn的那臺機器的相同位置，並把原來的txid文件給刪掉。

重新啟動OK啦！！！好開森！！！

參考博客：https://blog.csdn.net/amber_amber/article/details/46896719

啟動hadoop集群的時候只能啟動一個namenode，另一個報錯There appears to be a gap in the edit log. We expected txid 6, but got txid 10.