一, 问题描述
当我们多次格式化文件系统 (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 保持不变.
来源: http://www.bubuko.com/infodetail-3507973.html