背景:昨晚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
原文地址:https://www.cnblogs.com/xuziyu/p/10665176.html