hadoop2.0报错“There appears to be a gap in the edit log”

来源：互联网发布：名越seo 编辑：程序博客网时间：2024/06/05 10:22

今天升级集群的时候遇到了这个问题。解决问题的过程中，借机也巩固了下对namenode启动过程的理解。这个问题网上几乎没查到好的解决办法，Google出来的办法说让Recovery，对已经有很大数据量的线上集群来说，风险太大，不可取。所以只能自己读着源码一步一步分析，终于还是找到了解决方法.

问题描述：

因为要升级集群，所以先停服务-->做升级-->重启服务。但是在重启服务的时候，standby namenode启动失败，每次都是先启动成功，然后在加载元数据的时候失败，shutdown. 报错如下：

<span style="font-family:Microsoft YaHei;font-size:12px;">2015-07-15 16:26:44,305 FATAL org.apache.hadoop.hdfs.server.namenode.NameNode: Exception in namenode joinjava.io.IOException: There appears to be a gap in the edit log.  We expected txid 176531929, but got txid 176533587.        at org.apache.hadoop.hdfs.server.namenode.MetaRecoveryContext.editLogLoaderPrompt(MetaRecoveryContext.java:94)        at org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader.loadEditRecords(FSEditLogLoader.java:205)        at org.apache.hadoop.hdfs.server.namenode.<span style="color:#ff0000;">FSEditLogLoader.loadFSEdits(FSEditLogLoader.java:133)</span>        at org.apache.hadoop.hdfs.server.namenode.FSImage.loadEdits(FSImage.java:809)        at org.apache.hadoop.hdfs.server.namenode.FSImage.loadFSImage(FSImage.java:669)        at org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:276)        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:882)        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:629)        at org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:498)        at org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:554)        at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:720)        at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:704)        at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1354)        at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1420)2015-07-15 16:26:44,307 INFO org.apache.hadoop.util.ExitUtil: Exiting with status 12015-07-15 16:26:44,308 INFO org.apache.hadoop.hdfs.server.namenode.NameNode: SHUTDOWN_MSG: </span>

解决方法：

问题解决的过程就不多说了，总之还是一句话，遇到解决不了的问题，就读源码吧。搞清楚过程了，很多问题就都迎刃而解了。

namenode在启动的过程中，最重要的一个动作就是拼凑集群的元数据，有哪些文件和目录，分别存放在哪里等信息。这个重要的过程分两步：

（1）读取fsimage和edits数据，拼凑出元数据。注意，这里的元数据是指，有哪些目录和文件，每个文件有多大这样的信息。

（2）获取每个datanode的汇报信息，整合出完整的blockMap。这里就还包括文件和实际存储的映射关系，一个文件具体存放在那个节点。

查看日志中的报错信息，可以明显地看到，这个问题是发生在FSEditLogLoader.loadFSEdits这个方法中（我上面飘红的地方），也就是在获取edits文件时报错。这里要注意的一点是，在配置有ha的hadoop2.0集群中，namenode启动时的fsimage是直接从本地获取，而edits是从journalnode上获取的。 所以 “We expected txid 176531929, but got txid 176533587. ” 这个问题肯定是发生在journalnode上，而不是namenode上的。

网上有一种解决方法，说是把active namenode上的name文件夹拷贝到standby namenode上。我试了，而且拷贝过来的name目录中也有176531929这条Edits数据，但启动namenode时还是报同样的错，说找不到176531929这条edit数据。说明这个方法不可行！因为Edits是要在启动时去journalnode上读取的。这个问题的根本原因是你的journalnode上存在Edits数据丢失的情况。

所以我去查看我的journalnode目录，果然发现journalnode/yarncluster/current下面没有176531929这一条Edits数据。所以，这就是这个错误出现的根本原因。然后解决办法很简单，从active namenode上拷贝这条Edits数据到所有journalnode中。重新启动，问题解决，没有数据丢失，也不需要recovery。

0 0