查看原文
其他

Hadoop Namenode元数据持久化机制与SecondaryNamenode的作用详解

点击上方蓝色字体,选择“设为星标

回复”资源“获取更多资源

大数据技术与架构点击右侧关注,大数据开发领域最强公众号!

暴走大数据点击右侧关注,暴走大数据!

我们都知道namenode是用来存储元数据的,他并不是用来存储真正的数据。

那么他的元数据怎么进行持久化呢!

FsImage

文件系统的镜像文件叫fsImage,它包括了文件和块信息的映射,还有文件系统的属性信息。

datanode启动的过程中 首先会向namenode注册块信息,这些块信息就是存储在namenode的FsImage中的。

EditLog

对于文件系统的每一次更改,例如,增加文件,删除文件等操作都会被写入Edit Log 这个问题件中。

同样的,修改文件系统的副本因子配置,也会被写入Edit Log文件。

EditLog 文件和fsImage文件都存储在文件系统的本地路径中。

namenode在内存中存储了,整个文件系统的镜像和文件块映射信息。

元数据是可以被合并的,因此namenode有4GB的内存,就足以存储巨量的文件和目录。


namenode启动过程中发生了什么呢?


1、从硬盘读取FsImage 和EditLog文件。

2、将EditLog文件中的所有操作信息写入FsImage中。产生一个新的FsImage文件- - - -这一操作被称为checkpoint

3、产生一个新的空的EditLog文件


namenode启动的时候checkponit

namenode运行过程中和fsImage 与 EditLog的交互操作

SecondaryNamenode
很多人理解的SecondaryNamenode的作用就是对namenode的备份,当namenode宕机了, 可以快速用secondarynamenode 恢复回来。
其实 SecondaryNamenode的重要作用,是定期合并FsImage和EditLog文件。

考虑一个场景。当我们的namenode宕机了。我们需要读取EditLog文件合并fsImage文件做恢复。如果这个EditLog文件,非常非常大,那么可能仅仅是读EditLog文件,就需要很长很长时间,以至于我们的故障恢复效果很差。
所以SecondaryNameNode,定期合并FsImage和EditLog文件,并替换namenode上的旧的FsImage文件,生成新的EditLog文件,替换原来的旧的EditLog文件。这样可以保证SecondaryNameNode上的文件为最近的信息。当发生宕机时候,可以快速恢复。
欢迎点赞+收藏+转发朋友圈素质三连

文章不错?点个【在看】吧! 👇

: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存