SecondaryNameNode不就是NameNode的熱備嗎？

來源： https://www.jianshu.com/p/5b4dd843b29d

責編：小新

前言

HDFS SecondaryNameNode是幹什麼的？

這是道經典的基礎面試題，筆者問過面試者不少次（固然也被面試官問過不少次）。從印象看，大約有一半的被面試者沒法正確做答，給出的答案甚至有「不就是NameNode的熱備嘛」。本文來簡單聊聊相關的知識，爲節省篇幅，將SecondaryNameNode簡稱SNN，NameNode簡稱NN。

NN與fsimage、edits文件

NN負責管理HDFS中全部的元數據，包括但不限於文件/目錄結構、文件權限、塊ID/大小/數量、副本策略等等。客戶端執行讀寫操做前，先從NN得到元數據。當NN在運行時，元數據都是保存在內存中，以保證響應時間。

顯然，元數據只保留在內存中是很是不可靠的，因此也須要持久化到磁盤。NN內部有兩類文件用於持久化元數據：

• fsimage文件，以fsimage_爲前綴，是序列化存儲的元數據的總體快照；

• edits文件（又稱edit log），以edits_爲前綴，是順序存儲的元數據的增量修改（即客戶端寫入操做）日誌。

這兩類文件均存儲在${dfs.namenode.name.dir}/current/路徑下，以下圖所示。

可見，當前正在寫入的edits文件名會有"inprogress"標識，而seen_txid文件保存的就是當前正在寫入的edits文件的ID。

在任意時刻，最近的fsimage和edits文件的內容加起來就是全量元數據。NN在啓動時，就會將最近的fsimage文件加載到內存，並重放它以後記錄的edits文件，恢復元數據的現場。

SNN與checkpoint過程

爲了不edits文件過大，以及縮短NN啓動時恢復元數據的時間，咱們須要按期地將edits文件合併到fsimage文件，該合併過程叫作checkpoint（這個詞是真正被用爛了哈）。

因爲NN的負擔已經比較重，再讓它來進行I/O密集型的文件合併操做就不太科學了，因此Hadoop引入了SNN負責這件事。也就是說，SNN是輔助NN進行checkpoint操做的角色。

checkpoint的觸發由hdfs-site.xml中的兩個參數來控制。

• dfs.namenode.checkpoint.period：觸發checkpoint的週期長度，默認爲1小時。

• dfs.namenode.checkpoint.txns：兩次checkpoint之間最大容許進行的操做數，默認爲100萬。

只要知足上述兩個參數的條件之一，就會觸發checkpoint過程，敘述以下：

1. NN生成新的edits_inprogress文件，後續的修改日誌將寫入該文件中，以前正在寫的edits文件即爲待合併狀態。

2. 將待合併的edits文件和fsimage文件一塊兒複製到SNN本地。

3. SNN像NN啓動時同樣，將fsimage文件加載到內存，並重放edits文件進行合併。生成合並結果爲fsimage.chkpoint文件。

4. SNN將fsimage.chkpoint複製回NN，並重命名爲正式的fsimage文件名。

Hadoop官方給出的圖示以下。雖然文件名稱不一樣，但思想是同樣的。

若是開啓了NN高可用呢？

上面說的都是集羣只有一個NN的狀況。若是有兩個NN而且開啓了HA的話，SNN就沒用了——checkpoint過程會直接交給Standby NN來負責。Active NN會將edits文件同時寫到本地與共享存儲（QJM方案就是JournalNode集羣）上去，Standby NN從JournalNode集羣拉取edits文件進行合併，並保持fsimage文件與Active NN的同步。

---

- END -

有收穫就點個「在看」吧 ▼

本文分享自微信公衆號 - 老懞大數據（simon_bigdata）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。