hadoop--HDFS_NameNode和SecondaryNameNode工作机制
目錄
- NN和2NN工作機(jī)制
- 第一階段
- 第二階段
- Fsimage和Edits解析
- Fsimage和Edits概念
- oiv查看Fsimage文件
- oev查看Edits文件
- CheckPoint時(shí)間設(shè)置
NN和2NN工作機(jī)制
NameNode中的元數(shù)據(jù)是存儲(chǔ)在哪里?
元數(shù)據(jù)存在鏡像文件Fsimage和編輯日志Edist文件中。在Secondary NameNode節(jié)點(diǎn)中,會(huì)定期進(jìn)行Fsimage和Edits的拷貝與合并,保證元數(shù)據(jù)的更新。
1.假設(shè)存儲(chǔ)在NameNode節(jié)點(diǎn)的磁盤(pán)中,因?yàn)橐?jīng)常進(jìn)行隨機(jī)訪問(wèn)和響應(yīng)客戶請(qǐng)求,看起來(lái)效率過(guò)低;那應(yīng)該是在內(nèi)存中;
2.假設(shè)只存放在內(nèi)存中,一旦斷電,元數(shù)據(jù)丟失,整個(gè)集群便無(wú)法工作;
3.因此應(yīng)該是在存在磁盤(pán)中備份元數(shù)據(jù)的Fsimage中;但當(dāng)內(nèi)存中的元數(shù)據(jù)更新時(shí),如果同時(shí)更新Fsiamge,就會(huì)導(dǎo)致效率過(guò)低,但如果不更新,就會(huì)產(chǎn)生一致性問(wèn)題,一旦NameNode節(jié)點(diǎn)斷電,就會(huì)產(chǎn)生數(shù)據(jù)丟失;
4.所以還要引入Edits文件(只進(jìn)行追加操作,效率高),每當(dāng)元數(shù)據(jù)有更新或者添加元數(shù)據(jù)時(shí),修改內(nèi)存中的元數(shù)據(jù)并追加到Edits中。
這樣,當(dāng)NameNode節(jié)點(diǎn)斷電時(shí),可以通過(guò)Fsimage和Edits的合并,合成元數(shù)據(jù)。
5.但如果長(zhǎng)時(shí)間添加數(shù)據(jù)到Edits種,會(huì)導(dǎo)致該文件數(shù)據(jù)過(guò)大,效率降低,一旦斷電,恢復(fù)元數(shù)據(jù)需要的時(shí)間過(guò)長(zhǎng)。
所以,需要定期進(jìn)行Fsimage和Edits的合并,如果此操作由NameNode節(jié)點(diǎn)完成,效率過(guò)低;所有,再次引入一個(gè)新的節(jié)點(diǎn)Secondary NameNode,專門(mén)用于Fsimage和Edits的合并。
第一階段
1.第一次啟動(dòng)NameNode格式化后,創(chuàng)建Fsimage和Edits文件;
若非第一次啟動(dòng),直接加載編輯日志Edits和鏡像文件Fsimage到內(nèi)存;
2.客戶端對(duì)元數(shù)據(jù)進(jìn)行增刪改的請(qǐng)求;
3.NameNode記錄操作日志,更新滾動(dòng)日志;
4.NameNode在內(nèi)存中對(duì)元數(shù)據(jù)進(jìn)行增刪改。
第二階段
1.Secondary NameNode詢問(wèn)NameNode是否需要CheckPoint(定時(shí)1hr);
2.Secondary NameNode請(qǐng)求執(zhí)行CheckPoint (1min查看一次nn/ 磁盤(pán)已滿);
3.NameNode滾動(dòng)正在寫(xiě)的Edits日志;生成新的edits_inprogress_002, 將原來(lái)的名稱修改為edits_001;
4.將滾動(dòng)前的編輯日志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,每次啟動(dòng)NameNode的時(shí)候,都會(huì)加載一次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ù)的一個(gè)永久性的檢查點(diǎn),其中包含HDFS文件系統(tǒng)的所有目錄和文件inode的序列化信息;
2.Edits文件:存放HDFS文件系統(tǒng)的所有更新操作的路徑,文件系統(tǒng)客戶端執(zhí)行的所有寫(xiě)操作首先會(huì)被記錄到Edits文件中;
3.seen_exid文件保存的是一個(gè)數(shù)字,就是最后一個(gè)edits_的數(shù)字(最新的edits文件);
4.每次NameNode啟動(dòng)的時(shí)候都會(huì)將Fsimage文件讀入內(nèi)存,家在Edits里面的更新操作,保證內(nèi)存中的元數(shù)據(jù)信息是最新的、同步的,可以看成NameNode啟動(dòng)的時(shí)候就將Fsimage和Edits文件進(jìn)行了合并。
oiv查看Fsimage文件
1.查看oiv和oev命令:
oiv: 查看鏡像文件;
oev: 查看Edits文件;
2.基本語(yǔ)法:
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.基本語(yǔ)法
hdfs oev -p 文件類型 -i 編輯日志 -o 轉(zhuǎn)換后文件輸出路徑2.案例
[xiaobai@hadoop102 current]$ hdfs oev -p XML -i edits_inprogress_0000000000000003208 -o /opt/software/edits.xml問(wèn):NameNode如何確定下次開(kāi)機(jī)啟動(dòng)的時(shí)候合并哪些Edits?
合并數(shù)字最大的,時(shí)間戳最晚的。
CheckPoint時(shí)間設(shè)置
1.通常情況下,Secondary NameNode每隔1hr執(zhí)行一次;
2.1min檢查一次操作次數(shù),當(dāng)操作次數(shù)達(dá)到1百萬(wàn)次時(shí),Secondary NameNode執(zhí)行一次。
tips: 可在hdfs-default.xml中查看。
總結(jié)
以上是生活随笔為你收集整理的hadoop--HDFS_NameNode和SecondaryNameNode工作机制的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: Scale-up(纵向扩展) vs Sc
- 下一篇: 敏捷需求分析及深度提升(广州 2014.