Fsimage 與 EditLog定義及合併過程

有不少客戶端在向 hdfs 中寫數據，同時有不少客戶端在查數據，這就涉及到一個響應速度問題。由於只有一個 namenode ，客戶端在寫的時候，必須迅速記下來。

1. 向 namenode 詢問能夠存儲到哪些 datanode 中

2. 在 edits log（內存很小，是最新元數據的日誌） 中記錄最新的操做（只能追加，不能修改）

3. 返回給 client ，說哪些 DataNode 能夠寫

4. 在 HDFS 中，寫副本

5. 成功寫完以後，告訴 namenode

6. 元數據更新同步到 namenode 中的內存。這些操做才 edits log 中有記錄日誌，萬一內存中斷點，在 edits log 還有元數據。

 

edits log 假設只有 64M ，內存有 64 G ，元數據仍是得寫到 fsimage 中

若是 edits log 尚未滿，內存就暫時不須要同步到 fsimage 中，fsimage 與 edits log 保持同步：滿了，內存才須要同步到磁盤中。

 

edits log 與 fsimage 保持同步就是兩個合併在一塊兒。edits log 就是老數據了，此時就造成一個新的 edits log ，又寫。有個問題，edits log 中是日誌，fsimage 是元數據，格式不同，須要運算。

 

若是二者合併，那麼對客戶端的請求就會變慢。

 

具體的合併：

當 edits 滿了以後，就會開始執行

HTTP 的下載。

 

疑問：

在 checkpoint 以前，NN 故障宕機了，集羣還能正常對外提供服務嗎？

 

不能，由於 namenode 沒法查詢元數據了嘛，元數據仍是能夠恢復，可是在恢復以前，仍是不能提供服務。

1.secondary namenode經過週期性（五分鐘），經過getEditLog獲取editlog大小，當其達到合併的大小時經過RollEditLog方法進行合併。
2.namenode中止使用edits文件，並生成一個新的臨時的edits.new文件。
3.Secondarynamenode經過namenode內建的Http服務器，以get的方式獲取edits與fsimage文件。Get方法中攜帶着fsimage與edits的路徑。
4.Secondaryname將fsimage載入內存並逐一執行edits中的操做，生成新的fsimage文件。
5.執行結束後，會向namenode發送http請求，告知namenode合併結束，namenode經過http post的方式獲取新fsimage文件。
6.Namenode更新fsimage文件中記錄檢查點執行的時間，並更名爲fsimage文件。
7.Edit.new文件改名爲edit文件。
注：由此可知namenode 與 secondarynamenode 有着類似的內存需求，由於secondarynamenode也會將fsimage載入內存，所以secondarynamenode須要運行在一臺專門機器上。