hadoop--HDFS_NameNode和SecondaryNameNode工作机制
目錄
- 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中;但當(dāng)內(nèi)存中的元數(shù)據(jù)更新時,如果同時更新Fsiamge,就會導(dǎo)致效率過低,但如果不更新,就會產(chǎn)生一致性問題,一旦NameNode節(jié)點斷電,就會產(chǎn)生數(shù)據(jù)丟失;
4.所以還要引入Edits文件(只進行追加操作,效率高),每當(dāng)元數(shù)據(jù)有更新或者添加元數(shù)據(jù)時,修改內(nèi)存中的元數(shù)據(jù)并追加到Edits中。
這樣,當(dāng)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/current1.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文件;
2.基本語法:
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ù),當(dāng)操作次數(shù)達到1百萬次時,Secondary NameNode執(zhí)行一次。
tips: 可在hdfs-default.xml中查看。
總結(jié)
以上是生活随笔為你收集整理的hadoop--HDFS_NameNode和SecondaryNameNode工作机制的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Scale-up(纵向扩展) vs Sc
- 下一篇: 敏捷需求分析及深度提升(广州 2014.