一、定義

* The Secondary Namenode is a helper to the primary Namenode.
* The Secondary is responsible for supporting periodic checkpoints
* of the HDFS metadata. The current design allows only one Secondary
* Namenode per HDFs cluster.
* The Secondary Namenode is a daemon that periodically wakes
* up (determined by the schedule specified in the configuration),
* triggers a periodic checkpoint and then goes back to sleep.
* The Secondary Namenode uses the ClientProtocol to talk to the
* primary Namenode.

SecondNamenode是對主Namenode的一個補充，它會周期的執行對HDFS元數據的檢查點。
當前的設計僅僅允許每個HDFS只有單個SecondNamenode結點。
SecondNamenode是有一個后臺的進程，會定期的被喚醒（喚醒的周期依賴相關配置）執行檢查點任務，然后繼續休眠。
它使用ClientProtocol協議與主Namenode通信。

二、工作內容時序圖

* 如果NameNode崩潰并且硬盤損壞，可以從SecondaryNameNode拷貝fsimage文件，但是SecondaryNameNode最后一次合并之后的更新操作將會丟失。

三、工作內容解釋

1，檢查點到底是做什么用的呢？

先拋開SecondNamenode不說，先介紹下Namenode中與檢查點相關的兩個文件，以及他們之間的關系。
fsimage文件與edits文件是Namenode結點上的核心文件。
Namenode中僅僅存儲目錄樹信息，而關于BLOCK的位置信息則是從各個Datanode上傳到Namenode上的。
Namenode的目錄樹信息就是物理的存儲在fsimage這個文件中的，當Namenode啟動的時候會首先讀取fsimage這個文件，將目錄樹信息裝載到內存中。
而edits存儲的是日志信息，在Namenode啟動后所有對目錄結構的增加，刪除，修改等操作都會記錄到edits文件中，并不會同步的記錄在fsimage中。
而當Namenode結點關閉的時候，也不會將fsimage與edits文件進行合并，這個合并的過程實際上是發生在Namenode啟動的過程中。
也就是說，當Namenode啟動的時候，首先裝載fsimage文件，然后在應用edits文件，最后還會將最新的目錄樹信息更新到新的fsimage文件中，然后啟用新的edits文件。
整個流程是沒有問題的，但是有個小瑕疵，就是如果Namenode在啟動后發生的改變過多，會導致edits文件變得非常大，大得程度與Namenode的更新頻率有關系。
那么在下一次Namenode啟動的過程中，讀取了fsimage文件后，會應用這個無比大的edits文件，導致啟動時間變長，并且不可能控，可能需要啟動幾個小時也說不定。


Namenode的edits文件過大的問題，也就是SecondeNamenode要解決的主要問題。
SecondNamenode會按照一定規則被喚醒，然后進行fsimage文件與edits文件的合并，防止edits文件過大，導致Namenode啟動時間過長。

2，檢查點被喚醒的條件？

以前的文章里面曾經寫過相關內容，這里在回顧一下。
控制檢查點的參數有兩個，分別是：
fs.checkpoint.period：單位秒，默認值3600，檢查點的間隔時間，當距離上次檢查點執行超過該時間后啟動檢查點
fs.checkpoint.size：單位字節，默認值67108864，當edits文件超過該大小后，啟動檢查點
上面兩個條件是或的關系，主要滿足啟動一個條件，檢查點即被喚醒

3，檢查點執行的過程？

a，初始化檢查點
b，通知Namenode啟用新的edits文件
c，從Namenode下載fsimage和edits文件
d，調用loadFSImage裝載fsimage
e，調用loadFSEdits應用edits日志
f，保存合并后的目錄樹信息到新的image文件中
g，將新產生的image上傳到Namenode中，替換原來的image文件
h，結束檢查點

4，SecondNamenode最好于Namenode部署到不同的服務器

應該在merge的過程中，SecondNamenode對內存的需求與Namenode是相同的，所以對于那些大型的生產系統中，如果將兩者部署到同臺服務器上，在內存上會出現瓶頸。
所以最好將他們分別部署到不同的服務器。
修改hadoop配置文件的master文件。

5，關于SecondNamenode的思考

其實檢查點的執行過程最好在Namenode結點搞定，也就說能有個任務定期的將Namenode的內存結果刷新到fsimage中，而不是僅僅在Namenode啟動的時候才進行一次合并。
如果可以實現定期的對Namenode執行檢查點，那么SecondNamenode完全沒有存在的必要了。
或者在SecondNamenode方面實現增量的刷新，每次不需要將fsimage整個裝載到內存中，而僅僅將增量刷新就OK了。
不過這樣會讓系統變得復雜一些，可以參考oracle中的檢查點的處理，還是有些復雜的。
簡單就是美？！！

?FYI：在masters文件中配置second namenode后，日志報java.net.BindException: Cannot assign requested address異常，而且second namenode啟動失敗，反復測試發現是hdfs-site.xml中的dfs.secondary.http.address沒有更改IP，更改成masters中配置的IP后集群啟動正常。

? dfs.secondary.http.address
? second_namenode:50090
??
? ? The secondary namenode http server address and port.
? ? If the port is 0 then the server will start on a free port.

四、CheckPoint Node

可能是由于Secondary NameNode這個名字給人帶來的混淆，Hadoop后面的版本（1.0.4 ）建議不要使用Secondary NameNode，而使用CheckPoint Node。

Checkpoint Node和Secondary NameNode的作用以及配置完全相同，只是啟動命令不同 bin/hdfs namenode -checkpoint

五、Backup Node

Secondary NameNode和CheckPoint Node都只是提供一個fsimage更新和檢查點備份，并不提供NameNode 服務，當NameNode宕機的時候就會引起HDFS集群不可用。
Backup Node提供一個真正意義上的備用節點，NameNode所有寫操作都會實時將更新Log（edits文件數據）發送給Backup Node，Backup Node據此更新本機fsimage和edits文件，并在內存中維護和NameNode 一樣的Matadata數據。