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”文件夹及其内部文件的权限是否如下所示，authorized_keys 和 rsa的权限是600，其余文件权限是644.

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

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

chmod 600 ~/.ssh/authorized_keys

【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启动失败。