NameNode和SecondaruNode的工作机制------edits和fsimage工作机制

什么是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文件的大小。