SSH localhost免密不成功 + 集群状态显示Configured Capacity: 0 (0 KB)

时间:2023-03-10 04:57:16
SSH localhost免密不成功 + 集群状态显示Configured Capacity: 0 (0 KB)

前一天运行hadoop一切安好,今天重新运行出现BUG。下面对遇到的bug、产生原因以及解决方法进行一下简单总结记录。

【bug1】用ssh localhost免密登录时提示要输入密码。

原因分析:之前配置好了ssh免密登录并且ssh localhost以及ssh Slave1、ssh Master、ssh Slave2等都可以成功实现免密登录,后来突然想起前一天晚上用scp在节点之间传输文件的时候提示没有相关权限从而对节点的/home目录做过权限更改,而.ssh文件夹就在/home/hadoop目录下也即单独用cd命令而进入的主目录下(虽然用ls不会显示.ssh文件夹,但在home目录下用cd .ssh是可以进入的)。

SSH localhost免密不成功 + 集群状态显示Configured Capacity: 0 (0 KB)

解决方法:

查看”.ssh”文件夹及其内部文件的权限是否如下所示,authorized_keys 和 rsa的权限是600,其余文件权限是644.

SSH localhost免密不成功 + 集群状态显示Configured Capacity: 0 (0 KB)

如果权限不对则利用如下命令设置该文件的权限:

chmod 700 ~/.ssh #注意:这两条权限设置特别重要,决定成败。

chmod 600 ~/.ssh/authorized_keys

相关网址:http://blog.csdn.net/peace1213/article/details/51334508#t11

【bug2】配置后利用hadoop dfsadmin -report查看集群状态时,结果竟然是:

[hadoop@master logs]$ hadoop dfsadmin -report

Configured Capacity: 0 (0 KB)

Present Capacity: 0 (0 KB)

DFS Remaining: 0 (0 KB)

DFS Used: 0 (0 KB)

DFS Used%: ?%

Under replicated blocks: 0

Blocks with corrupt replicas: 0

Missing blocks: 0

使用jps小工具再查看一下:

namenode上:

17992 JobTracker

17910 SecondaryNameNode

18543 Jps

17748 NameNode

datanode上:

8601 Jps

8490 DataNode

8324 TaskTracker

看似一切正常,百思不得其解。

原因分析:由于开始【bug1】的出现,重新进行过集群格式化,使得子节点的clusterID、namespaceID与主节点(即namenode节点)的clusterID、namespaceID不一致。

解决方法:要先清理掉相关文件后再进行格式化。具体步骤及注意事项如下:

1>重新格式化意味着集群的数据会被全部删除,格式化前需考虑数据备份或转移问题;
2>先删除主节点(即namenode节点):Hadoop的临时存储目录tmp、namenode存储永久性元数据目录dfs/name、Hadoop系统日志文件目录log 中的内容 (注意是删除上述三个目录下的内容而不删除目录本身);
3>删除所有数据节点(即datanode节点) :Hadoop的临时存储目录tmp、namenode存储永久性元数据目录dfs/name、Hadoop系统日志文件目录log 中的内容(注意是删除上述三个目录下的内容而不删除目录本身);
4>重新格式化一个新的分布式文件系统:$ hadoop namenode -format

注意点:

(1)Hadoop的临时存储目录tmp(即core-site.xml配置文件中的hadoop.tmp.dir属性,默认值是/tmp/hadoop-${user.name}),如果没有配置hadoop.tmp.dir属性,那么hadoop格式化时将会在/tmp目录下创建一个目录,例如在cloud用户下安装配置hadoop,那么Hadoop的临时存储目录就位于/tmp/hadoop-cloud目录下
(2)Hadoop的namenode元数据目录(即hdfs-site.xml配置文件中的dfs.namenode.name.dir属性,默认值是${hadoop.tmp.dir}/dfs/name),同样如果没有配置该属性,那么hadoop在格式化时将自行创建。必须注意的是在格式化前必须清楚所有子节点(即DataNode节点)dfs/name下的内容,否则在启动hadoop时子节点的守护进程会启动失败。这是由于,每一次format主节点namenode,dfs/name/current目录下的VERSION文件会产生新的clusterID、namespaceID。但是如果子节点的dfs/name/current仍存在,hadoop格式化时就不会重建该目录,因此形成子节点的clusterID、namespaceID与主节点(即namenode节点)的clusterID、namespaceID不一致。最终导致hadoop启动失败。

相关网址:

http://www.cnblogs.com/neo98/articles/6305999.html

http://blog.csdn.net/xiao_jun_0820/article/details/8857017

http://blog.163.com/fafaly@126/blog/static/131693298201422911363274/