Hadoop Cluster啟動後資料節點（DataNode）程序狀態丟失

• 在擁有三個節點的Hadoop叢集環境中，其各節點的配置為：CPU Intel(R) Core(TM) i3-3120M [email protected] 2.50GHz,記憶體RAM 6GB,Operation System Redhat Linux 5 x86-64bit.

• 首先通過命令hadoop dfs namenode -format格式化名稱節點，格式化成功以後使用start-dfs.sh和start-yarn.sh指令碼啟動叢集。此時，整個Hadoop叢集使用 JPS程序檢視命令發現均正常。在沒有關閉Hadoop叢集的狀態下，我們使用了hadoop dfs namenode -format 命令重新格式化了名稱節點。此時再次啟動hadoop叢集，發現數據節點Datanode程序在成功啟動後不久就自動退出。我們重新進行了名稱節點的格式化和叢集的重啟，但是資料節點上的程序依舊在重啟後發生閃退的現象。經過查閱相關文獻，部落格
  http://my.oschina.net/liangtee/blog/161581幫助解決了這一問題，該博文內容如下。

Error 資訊 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Incompatible namespaceIDs in /var/lib/hadoop-0.20/cache/hdfs/dfs/data: namenode namespaceID = 240012870; datanode namespaceID = 1462711424 .

• 檢視日誌發現錯誤類似上面所示：顯示由於叢集中不相容的名稱空間版本號而導致資料節點Datanode發生系統I/O的錯誤。肯定是由於在重新初始化名稱空間的過程中發生了名稱空間版本不一致的情況。

why 問題：Namenode名稱節點的namespaceID與datanode資料節點的namespaceID不一致。

• 問題產生原因：每次 namenode format會重新建立一個namenodeId,而tmp/dfs/data下包含了上次format下的id , namenode  format 清空了namenode下的資料,但是沒有清空datanode下的資料,所以造成namenode節點上的namespaceID與datanode節 點上的namespaceID不一致。從而直接導致了資料節點啟動失敗。

• 解決方案1（會造成資料丟失，很難恢復找回）
• (1)停掉叢集服務，呼叫stop-dfs.sh和stop-yarn.sh指令碼。
• (2)在出問題的datanode節點上刪除data目錄，data目錄即是在 hdfs-site.xml檔案中配置的dfs.data.dir目錄，本機器上那個是/var/lib/hadoop-0.20/cache/hdfs /dfs/data/ (注：我們當時在所有的datanode和namenode節點上均執行了該步驟。以防刪掉後不成功，可以先把data目錄儲存一個副本).
• (3)格式化namenode，hadoop dfs namenode -format。
  
• (4)重新啟動叢集，呼叫start-dfs.sh和start-yarn.sh指令碼。
• 這種方法帶來的一個副作用即是，hdfs上的所有資料丟失。如果hdfs上存放有重要資料的時候，不建議採用該方法。其實，我們的目的就是要同步名稱節點和資料節點上的NamespaceID，如果有辦法可以直接同步該資料項 NamespaceID，那麼我們就能夠以最小程度的資料丟失實現Hadoop叢集的修復。該帖也指出了另一種解決方案如下。

• Workaround 1: Start from scratch

Solution-1 I can testify that the following steps solve this error, but the side effects won't make you happy (me neither). The crude workaround I have found is to:

1.stop the cluster

2.delete the data directory on the problematic datanode: the directory is specified by dfs.data.dir in conf/hdfs-site.xml; if you followed this tutorial, the relevant directory is /usr/local/hadoop-datastore/hadoop-hadoop/dfs/data

3.reformat the namenode (NOTE: all HDFS data is lost during this process!)

4.restart the cluster

When deleting all the HDFS data and starting from scratch does not sound like a good idea (it might be ok during the initial setup/testing), you might give the second approach a try.

• Workaround 2: Updating namespaceID of problematic datanodes

Solution-2 Big thanks to Jared Stehler for the following suggestion. I have not tested it myself yet, but feel free to try it out and send me your feedback. This workaround is "minimally invasive" as you only have to edit one file on the problematic datanodes:

1.stop the datanode

2.edit the value of namespaceID in <dfs.data.dir>/current/VERSION to match the value of the current namenode

3.restart the datanode

If you followed the instructions in my tutorials, the full path of the relevant file is /usr/local/hadoop-datastore/hadoop-hadoop/dfs/data/current/VERSION (background: dfs.data.dir is by default set to ${hadoop.tmp.dir}/dfs/data, and we set hadoop.tmp.dir to /usr/local/hadoop-datastore/hadoop-hadoop).

•  If you wonder how the contents of VERSION look like, here's one of mine:

#contents of <dfs.data.dir>/current/VERSION
namespaceID=393514426
storageID=DS-1706792599-10.10.10.1-50010-1204306713481
cTime=1215607609074
storageType=DATA_NODE
layoutVersion=-13

• 原 因:每次namenode format會重新建立一個namenodeId,而tmp/dfs/data下包含了上次format下的id,namenode format清空了namenode下的資料,但是沒有晴空datanode下的資料,導致啟動時失敗,所要做的就是同步名稱節點和資料節點下的所有 namespaceID。