什么是edits,什么是fsimage?
edits日志文件中存放的是操作,fsimage镜像文件存放的是最终文件状态的元数据。
为提高可靠性,先写入编辑日志中,再进行操作。
HDFS启动过程(edits和fsimage工作机制)
1)第一阶段:namenode启动
(1)第一次启动namenode格式化后,创建fsimage和edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
(2)客户端对元数据进行增删改的请求
(3)namenode记录操作日志,更新滚动日志。
(4)namenode在内存中对数据进行增删改查
2)第二阶段:Secondary NameNode工作(检查点机制)
(1)Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。(checkpoint触发条件,1.定时(每隔1小时定时请求)或者2.edits文件满了【100万次操作】)
(2)Secondary NameNode请求执行checkpoint。
(3)namenode滚动正在写的edits日志
(4)将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
(5)Secondary NameNode加载编辑日志和镜像文件到内存,并合并。
(6)生成新的镜像文件fsimage.chkpoint
(7)拷贝fsimage.chkpoint到namenode
(8)namenode将fsimage.chkpoint重新命名成fsimage
为什么要分成fsimage和edits?
fsimage是存于硬盘的元数据检查点,Hadoop不会对每个文件操作都写出到fsimage,这样是很慢的,但是每个文件操作都会在提交后运行前先写入edits编辑日志,这样在namenode出现故障后,就会将fsimage和edits编辑日志结合读入内存,重建元数据信息。为了避免edits编辑日志的无限制扩大,secondary namenode 就回按照时间阈值(比如1小时)或者按大小阈值(edits编辑日志文件大小超过64M,这些参数都可以设置)“周期性”的读取namenode中的edits和fsimage重构fsimage检查点,同时在namenode中进行edits的滚动,来解决这个问题。
fsimage和edits为什么要合并?
在NameNode运行期间,客户端对HDFS的写操作都保存到edits文件中,久而久之edits文件会变得很大,虽然这对NameNode运行的时候是没有影响的,但是在NameNode重启的时候,NameNode先将fsimage中的内容映射到内存中,然后再一条一条执行edits编辑日志中的操作当edits文件非常大的时候会导致namenode启动的时间非常漫长,而在这段时间中HDFS处于安全模式,所以需要在Namenode运行的时候将edits和fsimage定时进行合并,减小edits文件的大小。