SecondNamenode名字看起來很象是對第二個Namenode，要么與Namenode一樣同時對外提供服務，要么相當于Namenode的HA。
真正的了解了SecondNamenode以后，才發(fā)現(xiàn)事實并不是這樣的。
下面這段是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的一個補充，它會周期的執(zhí)行對HDFS元數(shù)據(jù)的檢查點。
當前的設計僅僅允許每個HDFS只有單個SecondNamenode結點。
SecondNamenode是有一個后臺的進程，會定期的被喚醒（喚醒的周期依賴相關配置）執(zhí)行檢查點任務，然后繼續(xù)休眠。
它使用ClientProtocol協(xié)議與主Namenode通信。

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

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

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

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

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

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

?

?FYI：在masters文件中配置second namenode后，日志報java.net.BindException: Cannot assign requested address異常，而且second namenode啟動失敗，反復測試發(fā)現(xiàn)是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.

轉載于:https://www.cnblogs.com/langren1992/p/6578658.html

總結

以上是生活随笔為你收集整理的hadoop SecondNamenode 详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。