目錄

• NN和2NN工作機制
• • 第一階段
  • 第二階段
• Fsimage和Edits解析
• • Fsimage和Edits概念
  • oiv查看Fsimage文件
  • oev查看Edits文件
• CheckPoint時間設(shè)置

NN和2NN工作機制

NameNode中的元數(shù)據(jù)是存儲在哪里？

元數(shù)據(jù)存在鏡像文件Fsimage和編輯日志Edist文件中。在Secondary NameNode節(jié)點中，會定期進行Fsimage和Edits的拷貝與合并，保證元數(shù)據(jù)的更新。

1.假設(shè)存儲在NameNode節(jié)點的磁盤中，因為要經(jīng)常進行隨機訪問和響應(yīng)客戶請求，看起來效率過低；那應(yīng)該是在內(nèi)存中；

2.假設(shè)只存放在內(nèi)存中，一旦斷電，元數(shù)據(jù)丟失，整個集群便無法工作；

3.因此應(yīng)該是在存在磁盤中備份元數(shù)據(jù)的Fsimage中；但當內(nèi)存中的元數(shù)據(jù)更新時，如果同時更新Fsiamge，就會導(dǎo)致效率過低，但如果不更新，就會產(chǎn)生一致性問題，一旦NameNode節(jié)點斷電，就會產(chǎn)生數(shù)據(jù)丟失；

4.所以還要引入Edits文件(只進行追加操作，效率高)，每當元數(shù)據(jù)有更新或者添加元數(shù)據(jù)時，修改內(nèi)存中的元數(shù)據(jù)并追加到Edits中。
這樣，當NameNode節(jié)點斷電時，可以通過Fsimage和Edits的合并，合成元數(shù)據(jù)。

5.但如果長時間添加數(shù)據(jù)到Edits種，會導(dǎo)致該文件數(shù)據(jù)過大，效率降低，一旦斷電，恢復(fù)元數(shù)據(jù)需要的時間過長。

所以，需要定期進行Fsimage和Edits的合并，如果此操作由NameNode節(jié)點完成，效率過低；所有，再次引入一個新的節(jié)點Secondary NameNode，專門用于Fsimage和Edits的合并。

第一階段

1.第一次啟動NameNode格式化后，創(chuàng)建Fsimage和Edits文件；
若非第一次啟動，直接加載編輯日志Edits和鏡像文件Fsimage到內(nèi)存；

2.客戶端對元數(shù)據(jù)進行增刪改的請求；

3.NameNode記錄操作日志，更新滾動日志；

4.NameNode在內(nèi)存中對元數(shù)據(jù)進行增刪改。

第二階段

1.Secondary NameNode詢問NameNode是否需要CheckPoint(定時1hr)；

2.Secondary NameNode請求執(zhí)行CheckPoint (1min查看一次nn/ 磁盤已滿)；

3.NameNode滾動正在寫的Edits日志；生成新的edits_inprogress_002， 將原來的名稱修改為edits_001；

4.將滾動前的編輯日志edits_001和鏡像文件fsimage拷貝到Secondary NameNode；

5.Secondary NameNode加載編輯日志edits_001和鏡像文件fsimage到內(nèi)存，并合并；

6.生成新的鏡像文件fsimage.chkpoint;

7.拷貝fsimage.chkpoint到NameNode；

8.NameNode將fsimage.chkpoint重新命名成fsimage(覆蓋)。

tips:
1.NameNode和Secondary NameNode的唯一區(qū)別：NameNode中記錄了最新的edits_inprogress_002操作；

2.最新的元數(shù)據(jù) = fsimage + edits_inprogress_002，每次啟動NameNode的時候，都會加載一次fsimage + edits_inprogress_002，保證內(nèi)存中的元數(shù)據(jù)是最新的。

Fsimage和Edits解析

Fsimage和Edits概念

NameNode被格式化之后，將在/opt/module/hadoop-3.2.2/data/dfs/name/current目錄下產(chǎn)生如下文件：

[xiaobai@hadoop102 current]$ pwd /opt/module/hadoop-3.2.2/data/dfs/name/current

1.Fsimage文件：HDFS文件系統(tǒng)元數(shù)據(jù)的一個永久性的檢查點，其中包含HDFS文件系統(tǒng)的所有目錄和文件inode的序列化信息；

2.Edits文件：存放HDFS文件系統(tǒng)的所有更新操作的路徑，文件系統(tǒng)客戶端執(zhí)行的所有寫操作首先會被記錄到Edits文件中；

3.seen_exid文件保存的是一個數(shù)字，就是最后一個edits_的數(shù)字(最新的edits文件)；

4.每次NameNode啟動的時候都會將Fsimage文件讀入內(nèi)存，家在Edits里面的更新操作，保證內(nèi)存中的元數(shù)據(jù)信息是最新的、同步的，可以看成NameNode啟動的時候就將Fsimage和Edits文件進行了合并。

oiv查看Fsimage文件

1.查看oiv和oev命令：
oiv: 查看鏡像文件；
oev: 查看Edits文件；

[xiaobai@hadoop102 current]$ hdfs oev apply the offline edits viewer to an edits file oiv apply the offline fsimage viewer to an fsimage

2.基本語法：

hdfs oiv -p 文件類型 -i 鏡像文件 -o 轉(zhuǎn)換后文件輸出路徑

3.案例

[xiaobai@hadoop102 current]$ hdfs oiv -p XML -i fsimage_0000000000000003207 -o /opt/software/fsimage.xml 2021-09-02 22:43:53,417 INFO offlineImageViewer.FSImageHandler: Loading 5 strings 2021-09-02 22:43:53,517 INFO namenode.FSDirectory: GLOBAL serial map: bits=29 maxEntries=536870911 2021-09-02 22:43:53,518 INFO namenode.FSDirectory: USER serial map: bits=24 maxEntries=16777215 2021-09-02 22:43:53,518 INFO namenode.FSDirectory: GROUP serial map: bits=24 maxEntries=16777215 2021-09-02 22:43:53,518 INFO namenode.FSDirectory: XATTR serial map: bits=24 maxEntries=16777215

將顯示的xml文件內(nèi)容拷貝到/opt/software/目錄下創(chuàng)建的fsimage.xml文件中

oev查看Edits文件

1.基本語法

hdfs oev -p 文件類型 -i 編輯日志 -o 轉(zhuǎn)換后文件輸出路徑

2.案例

[xiaobai@hadoop102 current]$ hdfs oev -p XML -i edits_inprogress_0000000000000003208 -o /opt/software/edits.xml

問：NameNode如何確定下次開機啟動的時候合并哪些Edits？
合并數(shù)字最大的，時間戳最晚的。

CheckPoint時間設(shè)置

1.通常情況下，Secondary NameNode每隔1hr執(zhí)行一次；

2.1min檢查一次操作次數(shù)，當操作次數(shù)達到1百萬次時，Secondary NameNode執(zhí)行一次。

tips: 可在hdfs-default.xml中查看。

總結(jié)

以上是生活随笔為你收集整理的hadoop--HDFS_NameNode和SecondaryNameNode工作机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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