2NN与NN之间的关系
思考:NameNode中的元数据时存储在哪里的?
首先,我们做个假设,如果存储在NameNode节点的磁盘中,因为经常需要进行随机访问,还有相应客户请求,必然是效率过低。因此,元数据需要存放在内存中。但如果只存在内存中,一旦断电,元数据丢失,整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。
这样又带来了新的问题,当在内存中的元数据更新时,如果同时更新FsImage
,就会导致效率过低,但如果不更新,就会发生一致性问题,一旦NameNode
节点断电,就会产生数据丢失。因此,引入Edits文件(只进行追加操作,效率很高)。每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到Edits中 . 这样,一旦NameNode
节点断电,可以通过FsImage
和Edits
的合并,合成元数据。
但是,长时间添加数据到Edits中,会导致该文件数据过大,效率降低,而且一旦断电,恢复元数据需要的时间过长。因此需要定期进行FsImage
和 Edits
的合并,如果这个操作由NameNode
节点完成又会效率过低。便引入一个新的节点SecondaryNameNode(2NN),专门用来FsImage和Edits的合并。
元数据的持久化
第一阶段: 启动NameNode
- 第一次启动NameNode格式化后,创建Fsimage和Edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
- 客户端对元数据进行增删改的请求。
- NameNode记录操作日志,更新滚动日志。
- NameNode在内存中对元数据进行增删改。
第二阶段: Secondary NameNode 工作
- Secondary NameNode 询问 NameNode 是否需要CheckPoint。直接带回NameNode是否检查结果。
- Secondary NameNode 请求CheckPoint。
- NameNode 滚动正在写的Edits日志。
- 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
- Secondary NameNode加载编辑日志和镜像文件到内存,并合并。
- 生成新的镜像文件Fsimage.chkpoint。
- 拷贝Fsimage.chkpoint到NameNode。
- NameNode将Fsimage.chkpoint重新命名成Fsimage。
CheckPoint时间设置
检查点(CheckPoint
)的目的是通过获取文件系统元数据的快照并将其保存到 FsImage
来确保 HDFS
具有文件系统元数据的一致视图。尽管直接从内存中读取 FsImage
很高效,但直接对 FsImage
进行增量编辑效率不高。我们不会修改每个编辑的 FsImage
,而是在 Editlog
中保留编辑内容。
在检查点期间,Editlog
的更改将应用于 FsImage
。可以以秒为单位的给定时间间隔(dfs.namenode.checkpoint.period
)触发检查点,或者在累积给定数量的文件系统事务(dfs.namenode.checkpoint.txns
)之后触发检查点。如果同时设置了这两个属性,则一旦满足其中一个阈值就可触发检查点。
注意:每当集群启动的时候,也会进行一次CheckPoint操作
Fsimage和Edits解析
- Fsimage文件: HDFS文件系统元数据的一个永久性的检查点,其中包含HDFS文件系统的所有目录和文件inode的序列号信息。
- Edits文件:存放HDFS文件系统的所有更新操作的路径。文件系统客户端执行的所有写操作首先会被记录到Edits文件中。
- seen_txid 文件保存的是一个数字,就是最后一个edits_的数字
- 每次NameNode启动的时候都会将Fsimage文件读取到内存中,加载Edits里面的更新操作,保证内存中的元数据信息是最新的,同步的,可以看成NameNode启动的时候就是将Fsimage和Edits文件进行合并。
注意: Edits每次操作不会删除,但是fsimage会做删除操作,每次只保存两个
查看Fsimage文件
oiv apply the offline fsimage viewer to an fsimage
oiv_legacy apply the offline fsimage viewer to an legacy fsimage
oev apply the offline edits viewer to an edits file
基础语法
hdfs oiv -p 文件类型 -i 镜像文件 -o 转换后文件输出路径
hdfs oev -p 文件类型 -i 镜像文件 -o 转换后文件输出路径
实例操作
将导出的xml文件用编辑器打开查看
重启集群