1 - NameNode 的啟動流程
1)Loading fsimage - 從 fsimage file 中讀取最新的後設資料快照(最近生成的 fsimage_xx);
2)Loading edits - 讀取 fsimage_xx 之後的所有事務的 edit logs,將 edit logs 中的操作重新執行一遍,此時 NameNode 就恢復到上次停止時的狀態了;
3)checkpoint - 將當前狀態寫入新的 checkpoint 中,即產生一個新的 fsimage_xx 檔案;
4)Safe mode - 等待各個 DataNodes 彙報自己的 block 資訊,形成 blockMap,然後退出安全模式。
此時 NameNode 啟動結束,等待接受使用者的操作請求,並把使用者操作寫入新的 edit log 中,定期進行 checkpoint,對後設資料執行快照。
2 - NameNode 的後設資料
NameNode 的所有操作及整個叢集的狀態都儲存在 後設資料 中,後設資料都儲存在 fsImage 和 eidts 檔案中。
它們的主要作用是:在叢集啟動時將叢集的狀態恢復到關閉前的狀態。
第一次啟動 NameNode 前的格式化(
hdfs namenode -format
)操作會建立 fsimage 和 edits 檔案。非第一次啟動,NameNode 會進行資料恢復:首先把 FSImage 檔案載入到記憶體中形成檔案系統映象,然後再把 EditLog 中 FsImage 的結束事務 id 之後的 EditLog 回放到這個檔案系統映象上。這個時候,叢集也就恢復到關閉前的狀態了。
它們的位置需要在 hdfs-site.xml
檔案中指定:
<!-- NameNode 後設資料的存放目錄 -->
<property>
<name>dfs.namenode.name.dir</name>
<value>file:/Users/healchow/data/hadoop/namenode</value>
</property>
<!-- NameNode 日誌檔案的存放目錄 -->
<property>
<name>dfs.namenode.edits.dir</name>
<value>file:/Users/healchow/data/hadoop/namenode/edits</value
</property>
2.1 EditLog 操作日誌
1)客戶端對 HDFS 的寫操作會首先被記錄在 edits 檔案中;
HDFS 客戶端提交的建立、移動、刪除檔案等 寫操作 的時候,NameNode 會首先把這些操作記錄在 EditLog 檔案中。
2)edits 修改完成之後,會再更新記憶體中的檔案系統映象;
edits 檔案會不斷增大(導致系統執行、重啟恢復等過程非常緩慢),在一定條件下會和 fsimage 檔案合併,從而減小 EditLog 檔案的體積。
3)記錄在 EditLog 中的每一個操作又稱為一個事務,每個事務有一個整數形式的事務 id 作為編號。
(臨時總結,不一定對)EditLog 就是事務日誌,主要作用是用來記錄寫操作,以支援系統的恢復。
2.2 檢視 EditLog 檔案
EditLog 會被切割成很多段,每一段稱為一個 Segment。正在寫入的 Segment 處於 in-progress
狀態,其檔名形如 edits_inprogress_${start_txid}
,其中 ${start_txid}
表示這個 Segment 的起始事務 id。
已經寫入完成的 Segment 處於 finalized
狀態,其檔名形如 edits_${start_txid}-${end_txid}
,其中 ${start_txid}
表示這個 Segment 的起始事務 id,${end_txid}
表示這個 Segment 的結束事務 id。
檢視 edits 中的檔案資訊
hdfs oev 回車後會顯示命令的幫助資訊:
cd ~/data/hadoop/namenode
hdfs oev -i edits_0000000000000000865-0000000000000000866 -p XML -o myedit.xml
2.3 FSImage 後設資料映象
1)FSImage 是 NameNode 中關於後設資料的映象,一般稱為檢查點的映象;
2)FSImage 是 NameNode 自上次 checkpoint 之後生成的後設資料,並不是實時的資料;
3)FSImage 儲存了 NameNode 管理下的所有 DataNode 的檔案和目錄資訊:
對檔案來說:包括檔案的 block、各個 block 所在的 DataNode,以及它們的修改時間、訪問時間等;
對目錄來說:包括修改時間、訪問許可權控制資訊(許可權、屬組)等。
FSImage 預設會儲存2個,由屬性 dfs.namenode.num.checkpoints.retained
控制。
記憶體中的 FSImage 用於 NameNode 向客戶端提供讀服務,而 EditLog 僅僅只是在資料恢復的時候發揮作用。
2.4 檢視 FSImage 檔案
FSImage 檔案的檔名形如 fsimage_${end_txid}
,其中 ${end_txid}
表示這個 FSImage 檔案的結束事務 id。
檢視 fsimage 中的檔案資訊:
hdfs oev 回車後會顯示命令的幫助資訊:
cd ~/bigdata/data/hadoop/namenode
hdfs oiv -i fsimage_0000000000000000864 -p XML -o hello.xml
3 - Checkpoint 檢查點操作
3.1 為什麼要 Checkpoint
HDFS 的每個寫操作都會寫入EditLog 中,隨著時間的積累 EditLog 會變的很大,極端情況下會佔滿整個磁碟。
另外,由於 NameNode 在啟動的時候,需要將 EditLog 中的操作重新執行一遍,過大的 EditLog 會延長 NameNode 的啟動時間。
所以,通過 Checkpoint 定期對後設資料進行合併。
3.2 Checkpoint 的過程
Checkpoint 會把 FSImage 和 EditLog 的內容進行合併生成一個新的 FSImage。
這樣在 NameNode 啟動的時候就不用將巨大的 EditLog 中的事務再執行一遍,而是直接載入合併之後的新 FSImage ,然後重新執行未被合併的 EditLog 檔案就可以了。
建立新 FSImage 的過程需要大量的I/O、記憶體等資源,為了減輕影響,可將 Checkpoint 過程放在 SecondaryNameNode 或 StandbyNameNode 中(不同機器上)。
NameNode 在 Checkpoint 的時候會限制使用者的訪問(Hadoop 進入安全模式,此時需要管理員使用 dfsadmin 的 save namespace 來建立新的檢查點);
4 - SNN 輔助管理 FSImage 和 EditLog
4.1 相關配置
SNN(SecondaryNameNode,備份 NameNode)節點要在 conf/masters
檔案中指定;
SNN 的 hdfs-site.xml
檔案中需要配置下述引數:
<property>
<name>dfs.http.address</name>
<value>host:50070</value>
</property>
SecondaryNameNode 會定期合併 FSImage 和 EditLog,把 EditLog的體積控制在一個合理的範圍內。
Checkpoint 的觸發條件取決於兩個引數,可在 NameNode / SNN 的 core-site.xml
中配置:
<!-- 兩次 checkpoint 的時間間隔,預設3600秒,即1小時 -->
<property>
<name>dfs.namenode.checkpoint.period</name>
<value>3600s</value>
</property>
<!-- 新生成的 EditLog 中積累的事務數量達到了閾值,預設1000000次。優先順序高於上述引數 -->
<property>
<name>dfs.namenode.checkpoint.txns</name>
<value>1000000</value>
</property>
<!-- 每隔多久檢查一次 HDFS 未記錄到檢查點的事務數,預設60秒 -->
<property>
<name>dfs.namenode.checkpoint.check.period</name>
<value>60s</value>
</property>
<!-- 一次記錄檔案的大小,預設64MB -->
<property>
<name>fs.checkpoint.size</name>
<value>67108864</value>
</property>
4.2 管理流程
1)SecondaryNameNode 通知 NameNode 停止使用 EditLog,暫時將新的寫操作存放到 edits.new
檔案;
2)SecondaryNameNode 通過 HTTP 的 GET 請求,從 NameNode 中獲取 FSImage 和 EditLog,將它們載入到記憶體中;
3)SecondaryNameNode 合併 FSImage 和 EditLog,合併完成後生成新的 FSImage;
4)SecondaryNameNode 通過 HTTP POST 請求方式,將新的 FSImage 傳送給 NameNode;
5)NameNode 把原有的 FSImage 替換為新的 FSImage,把 edits.new 變成 edits,同時更新 fstime(即最後一個檢查點的時間戳)。
參考資料
版權宣告
出處:部落格園-瘦風的南牆(https://www.cnblogs.com/shoufeng)
感謝閱讀,公眾號 「瘦風的南牆」 ,手機端閱讀更佳,還有其他福利和心得輸出,歡迎掃碼關注?
本文版權歸博主所有,歡迎轉載,但 [必須在頁面明顯位置標明原文連結],否則博主保留追究相關人士法律責任的權利。