Fsimage 与 EditLog定义及合并过程

有不少客户端在向 hdfs 中写数据，同时有不少客户端在查数据，这就涉及到一个响应速度问题。由于只有一个 namenode ，客户端在写的时候，必须迅速记下来。

1. 向 namenode 询问能够存储到哪些 datanode 中

2. 在 edits log（内存很小，是最新元数据的日志） 中记录最新的操做（只能追加，不能修改）

3. 返回给 client ，说哪些 DataNode 能够写

4. 在 HDFS 中，写副本

5. 成功写完以后，告诉 namenode

6. 元数据更新同步到 namenode 中的内存。这些操做才 edits log 中有记录日志，万一内存中断点，在 edits log 还有元数据。

 

edits log 假设只有 64M ，内存有 64 G ，元数据仍是得写到 fsimage 中

若是 edits log 尚未满，内存就暂时不须要同步到 fsimage 中，fsimage 与 edits log 保持同步：满了，内存才须要同步到磁盘中。

 

edits log 与 fsimage 保持同步就是两个合并在一块儿。edits log 就是老数据了，此时就造成一个新的 edits log ，又写。有个问题，edits log 中是日志，fsimage 是元数据，格式不同，须要运算。

 

若是二者合并，那么对客户端的请求就会变慢。

 

具体的合并：

当 edits 满了以后，就会开始执行

HTTP 的下载。

 

疑问：

在 checkpoint 以前，NN 故障宕机了，集群还能正常对外提供服务吗？

 

不能，由于 namenode 没法查询元数据了嘛，元数据仍是能够恢复，可是在恢复以前，仍是不能提供服务。

1.secondary namenode经过周期性（五分钟），经过getEditLog获取editlog大小，当其达到合并的大小时经过RollEditLog方法进行合并。
2.namenode中止使用edits文件，并生成一个新的临时的edits.new文件。
3.Secondarynamenode经过namenode内建的Http服务器，以get的方式获取edits与fsimage文件。Get方法中携带着fsimage与edits的路径。
4.Secondaryname将fsimage载入内存并逐一执行edits中的操做，生成新的fsimage文件。
5.执行结束后，会向namenode发送http请求，告知namenode合并结束，namenode经过http post的方式获取新fsimage文件。
6.Namenode更新fsimage文件中记录检查点执行的时间，并更名为fsimage文件。
7.Edit.new文件改名为edit文件。
注：由此可知namenode 与 secondarynamenode 有着类似的内存需求，由于secondarynamenode也会将fsimage载入内存，所以secondarynamenode须要运行在一台专门机器上。