Hadoop錯誤之namenode宕機的數據恢復

情景再現：

在修復hadoop集群某一個datanode無法啟動的問題時，搜到有一個答案說要刪除hdfs-site.xml中dfs.data.dir屬性所配置的目錄，再重新單獨啟動該datanode即可； 
問題就出在這個誤刪除上，當時是在namenode的hadoop/hdfs/目錄下，然后就執行了一個可怕的命令

rm -rf data rm -rf name #存儲namenode永久性元數據目錄

當時還不知道刪除這個的可怕，以為只是誤刪除了普通數據而已，然后再轉到datanode下再次執行刪除，再啟動datanode后就正常了，jps查看各項服務均已正常啟動 
然后晚上在執行一個job時，報錯了，說目錄不存在，到此我才意識到是我之前到誤刪導致到這個錯誤，當時把datanode節點調試成功后也沒試試執行一個job驗證hadoop環境到正確性。 
然后我就手動建了一個日志說找不到到目錄，重啟后報錯namenode is not formatted，就是說需要格式化namenode才行，到這里就傻眼了，格式化容易，可集群上幾個t的數據可能就沒了，這很闊怕。

解決歷程：

首先重啟集群，發現除了namenode外其他均成功啟動，這個時候使用

hdfs dfs -ls / 

這樣的命令去查看hdfs文件系統，是無法查看的，應該是報錯被拒絕。 
我們去查看 
http://192.168.1.148:50070/dfshealth.html#tab-datanode 
這個目錄，發現是無法訪問了，然后再去查看每個數據節點的使用量，使用命令

df -lh

發現幾個節點的使用量都不是為0，就是說集群的數據並沒有被刪除，還有恢復的可能，然后看到了幾篇hadoop數據恢復的文章 
1，hadoop主節點（NameNode）備份策略以及恢復方法 
2，hadoop集群崩潰恢復記錄 
3，模擬namenode宕機：數據塊損壞，該如何修復 
還有一篇介紹數據存儲的文章 
4，hadoop HDFS存儲原理

以下是正確的解決方案，耗時一天一夜，首先在本地偽分布式環境測試成功，然后移到集群環境中成功解決： 
1、存在一個正常的hadoop環境，hdfs上存在多個文件及文件夾 
2、刪除name目錄 
3、stop-all.sh 
4、執行namenode格式化操作

hadoop namenode -format

5、復制namesecondary/current下的VERSION文件夾里的三個id（clusterID，namespaceID，blockpoolID）到name/current的VERSION文件相應的值里 
6、復制namesecondary/current文件夾下fsimage開頭的鏡像文件到name到相應目錄下 
7、start-all.sh

PS：這里要注意一點，namesecondary里和data里的clusterID值一樣；name目錄指的是hdfs-site.xml中dfs.name.dir代表的目錄，這里是tmp/hdfs/name，同理data目錄；因為沒有配置secondary目錄，所以采用的是默認的配置，所以namesecondary指的是tmp/dfs/namesecondary