hadoop 2.6遇到的DataNode无法启动问题
2021/9/29 14:11:02
本文主要是介绍hadoop 2.6遇到的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 /usrlocal/hadoop/data/datanode(一般在你hadoop文件夹下面),能看到 data和name两个文件夹。
解决方法一:(推荐)
删除DataNode的所有资料及将集群中每个datanode节点的//data/current中的VERSION删除,然后重新执行hadoop namenode -format进行格式化,重启集群,错误消失。(及逐级查找删除datanode里面所有的version文件)
解决方法二:
将name/current下的VERSION中的clusterID复制到data/current下的VERSION中,覆盖掉原来的clusterID
让两个保持一致
然后重启,启动后执行jps,查看进程
出现该问题的原因:在第一次格式化dfs后,启动并使用了hadoop,后来又重新执行了格式化命令(hdfs namenode -format),这时namenode的clusterID会重新生成,而datanode的clusterID 保持不变。
————————————————
版权声明:本文为CSDN博主「GQ君」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/baidu_16757561/article/details/53698746
这篇关于hadoop 2.6遇到的DataNode无法启动问题的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2023-05-13Windows下hadoop环境搭建之NameNode启动报错
- 2023-04-14hadoop伪分布式集群的安装(不是单机版)
- 2022-12-05Hadoop生态系统—数据仓库Hive的安装
- 2022-11-02Win10搭建Hadoop环境
- 2022-10-19Hadoop生态系统(数据仓库Hive的安装)
- 2022-10-03Hadoop、storm和Spark Streaming简单介绍
- 2022-10-03胖虎的Hadoop笔记——Hadoop的伪分布式部署
- 2022-09-11Ubuntu搭建全分布式Hadoop
- 2022-09-11Ubuntu搭建全分布式Hadoop
- 2022-09-09Ubuntu下安装伪分布式HADOOP遇到的一些问题