Hadoop錯誤之namenode宕機的資料恢復

2021-09-07 17:44:02 字數 1574 閱讀 2366

在修復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檔案系統，是無法檢視的，應該是報錯被拒絕。 

我們去檢視 

這個目錄，發現是無法訪問了，然後再去檢視每個資料節點的使用量，使用命令

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

Hadoop 原始碼解析 No 1 NameNode

注 本人使用的版本是 2.9，並且確保你的機器上已經安裝了source 在新版的hadoop 當中 啟動模式已經從 bin hadoop bin hdfs我們開啟這個檔案 if command namenode then class org.apache.hadoop.hdfs.server.nam...

hadoop集群新增和格式化namenode的步驟

clusterid 新增了乙個新的識別符號clusterid用於標識集群中所有的節點。當格式化乙個namenode，需要提供這個識別符號或者自動生成。這個id可以被用來格式化加入集群的其他namenode。格式化namenodes 第一步 使用如下命令格式化乙個namenode hadoop pre...

hadoop執行錯誤總結

一 hadoop集群在namenode格式化 bin hadoop namenode format 後重啟集群會出現如下 incompatible namespaceids in namenode namespaceid datanode namespaceid 錯誤，原因是格式化namenode後...