Hadoop Backup Node

要了解Hadoop Backup Node，要從Namenode的元數據說起。

我們都知道Namenode的元數據非常重要，如果元數據損壞，所有存儲在datanode中的數據都讀不出來了。另外，如果Namenode的元數據比較大，那麼集羣的啓動速度非常慢。爲了解決這兩個問題，Hadoop弄了一個Secondary Namenode。

Namenode的元數據：
Hadoop Namenode元數據主要是兩個文件：edits和fsimage。fsimage是HDFS的最新狀態（截止到fsimage文件創建時間的最新狀態）文件，而edits是自fsimage創建後的namespace操作日誌。Namenode每次啓動的時候，都要合併兩個文件，按照edits的記錄，把fsimage文件更新到最新。

如果是一個大的、比較繁忙的集羣，它的edits文件增長會非常快，這樣下次Namenode重啓的過程會非常慢，因爲它要進行大量的操作。爲了加速啓動過程，同時爲了元數據的安全考慮，Hadoop搞了一個Secondary Namenode，它一般是一臺獨立的機器，內存大小與Namenode服務器相同。

Scondary Namenode：
Secondary Namenode定期地從Namenode上獲取元數據。當它準備獲取元數據的時候，就通知Namenode暫停寫入edits文件。Namenode收到請求後停止寫入edits文件，之後的log記錄寫入一個名爲edits.new的文件。Scondary Namenode獲取到元數據以後，把edits文件和fsimage文件在本機進行合併，創建出一個新的fsimage文件，然後把新的fsimage文件發送回Namenode。Namenode收到Secondary Namenode發回的fsimage後，就拿它覆蓋掉原來的fsimage文件，並刪除edits文件，把edits.new重命名爲edits。
通過這樣一番操作，就避免了Namenode的edits日誌的無限增長，加速Namenode的啓動過程。
但是Scondary Namenode有其自身的弱點，如checkpoint數據較舊，數據不一致等，新版本的hadoop已經把它放棄了，轉而使用更加高效的Backup Node。

來看一下Backup Node：
Backup Node在內存中維護了一份從Namenode同步過來的fsimage，同時它還從namenode接收edits文件的日誌流，並把它們持久化硬盤，Backup Node把收到的這些edits文件和內存中的fsimage文件進行合併，創建一份元數據備份。Backup Node高效的祕密就在這兒，它不需要從Namenode下載fsimage和edit，把內存中的元數據持久化到磁盤然後進行合併即可。
目前，hadoop集羣只支持一個Backup Node，如果Backup Node出了問題，Hadoop元數據的備份機制也就失效了，所以hadoop計劃在未來能支持多個Backup Node。

Backup Node的配置與啓動：
和它有關的配置項，需要注意的是，Namenode和Backup Node都要配置這些選項：
hdfs-site.xml：dfs.backup.address、dfs.backup.http.address
core-site.xml：fs.checkpoint.period、fs.checkpoint.size、fs.checkpoint.dir、fs.checkpoint.edits.dir
啓動：
在dfs.backup.address配置的節點上，運行bin/hdfs namenode -checkpoint

但是非常扯淡的是，雖然hadoop-1.0.3的官方hdfs用戶文檔中說放棄了Secondary Namenode，建議使用Backup Node，但在default配置文件中找不到關於backupnode的相關配置，反而secondary namenode的配置還保留着。到網上搜了一下，好像hadoop 1.0.3中並沒有啓用Backup Node，實際的原因是，hadoop 1.0.x完全是Apache的惡搞，Apache把hadoop 0.20.205直接命名成了hadoop 1.0！這麼坑爹的事情都有！而Backup Node是Hadoop 0.21、0.22（0.23，它是0.22的超集）版本里的東西，這麼多hadoop版本，功能都還不一樣！

混亂的Apache Hadoop版本。

Namenode元數據恢復流程：
1、啓動Backup Node
2、在Namenode上清空dfs.name.dir下的文件
3、在Namenode上執行命令：bin/hadoop namenode -importCheckpoint

hadoop還有哪些手段來保證namenode元數據的安全？
1) 對dfs.name.dir配置多個路徑，保存一份元數據到遠程主機。這樣，加上Backup Node上的元數據，我們就有了三份元數據。我們的配置：

<property>
<name>dfs.name.dir</name>
<value>/usr/local/hadoop/name,/home/hd_nn_remote_backup</value>
</property>

 需要注意的是，如果配置了多個路徑，在恢復Namenode元數據時，要同時清空這些目錄下的文件。
/home/hd_nn_remote_backup是一個遠程主機目錄，通過NFS掛載到本地；

2) Namenode熱備。目前的熱備方案有Facebook的Avatar、DRBD等。 

 

一次Namenode恢復實踐：

我們的環境是RHEL 5.6，Apache Hadoop 1.0.3。由於未採用Backup Node，我們仍然使用的是Secondary Namenode的配置，所以跟Backup Node的數據恢復有點不太一樣。

上週五，由於服務器在重啓時忘記停掉Hadoop集羣，導致了Namenode元數據損壞，所以進行了一次恢復操作。遺憾的是，由於Secondary Namenode獲取Namenode元數據時出了問題，而我們沒有及時注意到這個情況，導致恢復出來的數據丟失了幾天的量。這裏提醒大家一下，到Namenode機器的dfs.name.dir目錄下看一看，如果Hadoop把大量的日誌記錄在edits.new，而不是edits文件，那你就要小心了，可能Secondary Namenode那邊出了狀況，要及時查看日誌，解決問題。一般地，如果未配置dfs.secondary.address和dfs.secondary.http.address，會導致這個問題。

恢復過程比較簡，大略如下：

1、刪除Namenode上的dfs.name.dir目錄下所有的文件，如果配置了多個目錄，要全部清空

2、複製Secondary Namenode上的fs.checkpoint.dir目錄下的所有文件到Namenode的fs.checkpoint.dir目錄下

3、在Namenode上執行bin/hadoop namenode -importCheckpoint

4、ctrl + c終止會話，刪除NN上的scondary目錄下的文件

5、正式啓動Namenode：bin/hadoop-daemon.sh start namenode

6、bin/hadoop dfsadmin -safemode leave

 

上面的方法分幾個步驟，很囉嗦，最簡單的方法是：把Secondary Namenode上的fs.checkpoint.dir目錄下的current下的文件複製到Namenode的dfs.name.dir目錄下的current目錄中，然後啓動namenode！

上面兩個恢復的方法，我都是親自試過，都是可以的。