提出问题

由 hadoop3.x：FsImage、Edits作用 可知：

如果长时间添加数据到 Edits 中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。

解决

需要定期进行 FsImage 和 Edits 的合并，如果这个操作由 NameNode 节点完成，又会效率过低。

因此，引入一个新的节点 SecondaryNamenode，专门用于 FsImage 和 Edits 的合并。

SecondaryNameNode(2NN)

作用：帮助NameNode进行Edits和Fsimage的合并工作

合并：将 Edits 和 Fsimage 加载到内存中，照着 Edits 中的操作一步步执行，最终形成新的Fsimage

操作过程

NameNode 格式化

NameNode格式化后，创建 Fsimage_x 文件

NameNode 第一次启动

先滚动Edits并生成一个空的 edits_inprogress_x 文件

NameNode 再次启动

1. 先滚动Edits（将 edits_inprogress_x 改名为 edits_x），并生成一个空的 edits_inprogress_x 文件

2. 加载 Fsimage_x 文件、edits_x 文件到内存，此时是最新的元数据信息

客户端操作文件

客户端向 NameNode 发送元数据的增删改的请求（如：上传、删除），NameNode 做以下操作：

1. 将操作日志 记录到 edits_inprogress_x 文件

2. 然后在内存中对数据进行增删改

提示：查询操作不会记录，因为查询不会修改元数据

注意：不能先修改内存中的数据，否则突然断电，来不及记录到 文件中，导致数据丢失

Secondary NameNode工作机制

1. Secondary NameNode询问NameNode是否需要CheckPoint。
   提示：满足下面一个条件就触发CheckPoint：

   • 定时时间到了
   • Edits中数据写满了

2. Secondary NameNode请求执行CheckPoint。

3. NameNode滚动正在写的Edits日志 （将 edits_inprogress_x 改名为 edits_x），并生成一个空的 edits_inprogress_x+1 文件

4. 将 Fsimage_x 文件、edits_x 文件 发送到Secondary NameNode
   保存路径： hadoop3的/program/hadoop-3.0.3/data/tmp/dfs/namesecondary/current/ 目录下

5. Secondary NameNode加载 Fsimage_x 文件、edits_x 文件到内存，并合并

6. 生成新的镜像文件 fsimage.chkpoint

7. 将 fsimage.chkpoint 发送到NameNode。

8. NameNode将 fsimage.chkpoint 重新命名成 fsimage

NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可，因为合并过的Edits中的元数据信息已经被记录在Fsimage中

参考文章：
https://cloud.tencent.com/developer/article/1887713

原文出处：/show_1IX3tJB6NtDy.html