hadoop 2.6遇到的DataNode无法启动问题

最新推荐文章于 2021-06-17 15:35:55 发布

qmys

最新推荐文章于 2021-06-17 15:35:55 发布

阅读量246

点赞数

分类专栏：大数据

大数据专栏收录该内容

26 篇文章

订阅专栏

本文解析了Hadoop集群中DataNode无法启动的问题，详细介绍了由于NameNode和DataNode的clusterID不匹配导致的故障原因。提供了两种解决方案，一是删除DataNode的所有资料并重新格式化，二是手动同步clusterID，确保集群稳定运行。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、问题描述
当我们多次格式化文件系统（hadoop namenode -format）时，会出现DataNode无法启动。
多次启动中发现有NameNode节点，并没有DataNode节点
如图所示：

二、查看问题
回头看启动过程

注意如下：
localhost: starting datanode, logging to /usr/local/hadoop/logs/hadoop-hadoop-datanode-localhost.localdomain.out
查看相关日志：
/usr/local/hadoop/logs/hadoop-hadoop-datanode-localhost.localdomain.log
注意查看.log的文件，这是相关日志，而不是看.out文件
部分日志如下：

从日志上看，加粗的部分说明了问题
datanode的clusterID 和 namenode的clusterID 不匹配。
三、问题产生
当我们执行文件系统格式化时，会在namenode数据文件夹（即配置文件中dfs.name.dir在本地系统的路径）中保存一个current/VERSION文件，记录namespaceID，标志了所有格式化的namenode版本。如果我们频繁的格式化namenode，那么datanode中保存（即dfs.data.dir在本地系统的路径）的current/VERSION文件只是你地第一次格式化时保存的namenode的ID，因此就会造成namenode和datanode之间的ID不一致。
四、解决办法
根据日志中的路径，cd /home/hadoop/tmp/dfs（一般设置的dfs.name.dir在本地系统的路径），能看到 data和name两个文件夹。
解决方法一：（推荐）
删除DataNode的所有资料及将集群中每个datanode节点的/dfs/data/current中的VERSION删除，然后重新执行hadoop namenode -format进行格式化，重启集群，错误消失。
解决方法二：
将name/current下的VERSION中的clusterID复制到data/current下的VERSION中，覆盖掉原来的clusterID

让两个保持一致
然后重启，启动后执行jps，查看进程

出现该问题的原因：在第一次格式化dfs后，启动并使用了hadoop，后来又重新执行了格式化命令（hdfs namenode -format)，这时namenode的clusterID会重新生成，而datanode的clusterID 保持不变。