站长资源电脑基础

Hadoop datanode重新加载失败无法启动现象解决方法介绍

整理:jimmy2024/12/28浏览2
简介笔者使用的是基于虚拟机的Hadoop分布式安装,由于关闭datanode和namenode的顺序不恰当,所以经常会出现datanode加载失败的情况。本人的解决方法适用于首次已经成功启动整个集群,但是由于不正常的操作造成第二次无法正常启动。首次的启动失败可能原因有很多:可能是由于配置文件错误写入造

笔者使用的是基于虚拟机的Hadoop分布式安装,由于关闭datanode和namenode的顺序不恰当,所以经常会出现datanode加载失败的情况。

本人的解决方法适用于首次已经成功启动整个集群,但是由于不正常的操作造成第二次无法正常启动。首次的启动失败可能原因有很多:可能是由于配置文件错误写入造成的,或是由于ssh无密码登陆配置错误造成。

而第二次的错误原因与首次启动的有一些区别,排错重点应该集中在程序在运行中的一些动态加载而生成的文件上,笔者要讨论的是第二种情况:

大多原因就是因为hadoop的datanode的VERSION文件中的namespaceID与namenode中的VERSION文件中的namespaceID二者出现不一致的情况。而namespaceID的生成笔者推断应该是在执行:hdfs namenode -format 这个命令的时候生成的。

解决步骤如下:

1,首先停掉namenode上相关的进程:切换到hadoop的/sbin目录下:

sh  stop-dfs.sh

sh stop-yarn.sh

2,切换到hadoop的相应/current目录下将current下的所有文件清除。

3,将datanode与namenode的/current 下VERSION等相应文件文件清除后,回到namenode上,执行hsfs namenode -format命令,接着切换到namenode的hadoop的/sbin目录下:

执行sh start-dfs.sh

sh start-yarn.sh

(旧版本的mapre  被新版本的yarn所替代,命令上多少有些不同)

既可以看到相应的节点成功加载。

相应的思想就是,当出错时,清除掉一切干扰思路的文件,然后整理思绪,重新开始,这样要远比在原地徘徊要好。

(由于我们在配置文件中指明的文件夹只有  hdfs tmp log,所以其余的文件也好文件夹也好都是动态执行脚本生成创建的,删除之后只要hadoop整个系统可以工作就会生成,即便错删,VM的 snapshot 也会拯救这个世界。)