Hadoop Cluster启动后数据节点（Datanode）进程状态丢失

摘要: Hadoop Cluster在运行的过程中进行名称节点Namenode的重新初始化，致使重新启动集群后数据节点进程Datanode状态丢失。

【Askerain-2015070602】

在拥有三个节点的Hadoop集群环境中，其各节点的配置为：CPU Intel(R) Core(TM) i3-3120M CPU@2.50GHz 2.50GHz,内存RAM 6GB,Operation System Redhat Linux 5 x86-64bit.

首先通过命令hadoop dfs namenode -format格式化名称节点，格式化成功以后使用start-dfs.sh和start-yarn.sh脚本启动集群。此时，整个Hadoop集群使用JPS进程查看命令发现均正常。在没有关闭Hadoop集群的状态下，我们使用了hadoop dfs namenode -format 命令重新格式化了名称节点。此时再次启动hadoop集群，发现数据节点Datanode进程在成功启动后不久就自动退出。我们重新进行了名称节点的格式化和集群的重启，但是数据节点上的进程依旧在重启后发生闪退的现象。经过查阅相关文献，博客http://my.oschina.net/liangtee/blog/161581帮助解决了这一问题，该博文内容如下。

ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Incompatible namespaceIDs in /var/lib/hadoop-0.20/cache/hdfs/dfs/data: namenode namespaceID = 240012870; datanode namespaceID = 1462711424 .

查看日志发现错误类似上面所示：显示由于集群中不兼容的命名空间版本号而导致数据节点Datanode发生系统I/O的错误。肯定是由于在重新初始化名称空间的过程中发生了命名空间版本不一致的情况。

问题：Namenode名称节点的namespaceID与datanode数据节点的namespaceID不一致。

问题产生原因：每次namenode format会重新创建一个namenodeId,而tmp/dfs/data下包含了上次format下的id , namenode format 清空了namenode下的数据,但是没有清空datanode下的数据,所以造成namenode节点上的namespaceID与datanode节点上的namespaceID不一致。从而直接导致了数据节点启动失败。

解决方案1（会造成数据丢失，很难恢复找回）

(1)停掉集群服务，调用stop-dfs.sh和stop-yarn.sh脚本。

(2)在出问题的datanode节点上删除data目录，data目录即是在hdfs-site.xml文件中配置的dfs.data.dir目录，本机器上那个是/var/lib/hadoop-0.20/cache/hdfs/dfs/data/ (注：我们当时在所有的datanode和namenode节点上均执行了该步骤。以防删掉后不成功，可以先把data目录保存一个副本).

(3)格式化namenode，hadoop dfs namenode -format。

(4)重新启动集群，调用start-dfs.sh和start-yarn.sh脚本。

这种方法带来的一个副作用即是，hdfs上的所有数据丢失。如果hdfs上存放有重要数据的时候，不建议采用该方法。其实，我们的目的就是要同步名称节点和数据节点上的NamespaceID，如果有办法可以直接同步该数据项NamespaceID，那么我们就能够以最小程度的数据丢失实现Hadoop集群的修复。该帖也指出了另一种解决方案如下。

Workaround 1: Start from scratch

I can testify that the following steps solve this error, but the side effects won't make you happy (me neither). The crude workaround I have found is to:

1.stop the cluster

2.delete the data directory on the problematic datanode: the directory is specified by dfs.data.dir in conf/hdfs-site.xml; if you followed this tutorial, the relevant directory is /usr/local/hadoop-datastore/hadoop-hadoop/dfs/data

3.reformat the namenode (NOTE: all HDFS data is lost during this process!)

4.restart the cluster

When deleting all the HDFS data and starting from scratch does not sound like a good idea (it might be ok during the initial setup/testing), you might give the second approach a try.

Workaround 2: Updating namespaceID of problematic datanodes

Big thanks to Jared Stehler for the following suggestion. I have not tested it myself yet, but feel free to try it out and send me your feedback. This workaround is "minimally invasive" as you only have to edit one file on the problematic datanodes:

1.stop the datanode

2.edit the value of namespaceID in <dfs.data.dir>/current/VERSION to match the value of the current namenode

3.restart the datanode

If you followed the instructions in my tutorials, the full path of the relevant file is /usr/local/hadoop-datastore/hadoop-hadoop/dfs/data/current/VERSION (background: dfs.data.dir is by default set to ${hadoop.tmp.dir}/dfs/data, and we set hadoop.tmp.dir to /usr/local/hadoop-datastore/hadoop-hadoop).

If you wonder how the contents of VERSION look like, here's one of mine:

#contents of <dfs.data.dir>/current/VERSION

namespaceID=393514426

storageID=DS-1706792599-10.10.10.1-50010-1204306713481

cTime=1215607609074

storageType=DATA_NODE

layoutVersion=-13

原因:每次namenode format会重新创建一个namenodeId,而tmp/dfs/data下包含了上次format下的id,namenode format清空了namenode下的数据,但是没有晴空datanode下的数据,导致启动时失败,所要做的就是同步名称节点和数据节点下的所有namespaceID。