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
相关网址：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/
