hadoop SecondNamenode詳解

SecondNamenode名字看起來很象是對第二個Namenode，要麼與Namenode一樣同時對外提供服務，要麼相當於Namenode的HA。
真正的瞭解了SecondNamenode以後，才發現事實並不是這樣的。
下面這段是Hadoop對SecondNamenode的準確定義：

* 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通訊。

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後叢集啟動正常。

<property>
  <name>dfs.secondary.http.address</name>
  <value>second_namenode:50090</value>
  <description>
    The secondary namenode http server address and port.
    If the port is 0 then the server will start on a free port.
  </description>
</property>