1. 程式人生 > >SSH localhost免密不成功 + 集群狀態顯示Configured Capacity: 0 (0 KB)

SSH localhost免密不成功 + 集群狀態顯示Configured Capacity: 0 (0 KB)

cit 成功 數據節點 miss log height net tmp 權限

前一天運行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查看集群狀態時,結果竟然是:

[[email protected] 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/[email protected]/blog/static/131693298201422911363274/

SSH localhost免密不成功 + 集群狀態顯示Configured Capacity: 0 (0 KB)