背景：昨晚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 。”本人在查看edit的時候並沒有看見txid是6或者10 的情況，最后就抱着試一試的態度
把/home/hadoop/app/hadoop-2.6.0-cdh5.7.0/data/dfs/jn/ruozeclusterg6/current中的所有的edit*的文件都刪除，然后去active的nn的
/home/hadoop/app/hadoop-2.6.0-cdh5.7.0/data/dfs/name/current目錄下的所有的edit*文件復制到/home/hadoop/app/hadoop-2.6.0-cdh5.7.0/data/dfs/jn/ruozeclusterg6/current中，重啟成功啦！！！！，因為我jps的時候看見了namenode，但是當我第二次查看的時候，namenode竟然消失了，kao！！！好想哭！！！！！！
接着我又嘗試恢復原數據的解決方式，第一次嘗試因為中途出現了選項，我不知道改選什么，所以失敗了，我又找到一篇文章，里邊的信息是這樣的
解決方法：恢復一下namenode
cd $HADOOP_HOME/bin
hadoop namenode -recover
一路選擇c 進行元數據的恢復.這是重點
重新啟動。到這里問題真正的結束了，好舒服。
參考博客：https://blog.csdn.net/amber_amber/article/details/46896719