HDFS – 什么是元数据咱们提到了 CheckPoint 机制，次要就是合并多个 edits 文件，NameNode 的压力曾经很大了，所以合并的事件，并不是 NameNode 来做的，而是 SecondaryNamenode 来反对的，如果在高可用集群或者联邦集群，那合并的事件，就是有 standby 节点的 NameNode 来做的。

SecondaryNamenode

HDFS – 什么是元数据中提到了磁盘中的元数据包含 fsimage、edits_inprogress、edits、seen_txid、VERSION 这些文件。
刚开始的时候，是没有 edits 文件的。

当 NameNode 运行一段时间后，就开始缓缓的生成多个 edits 文件，文件名格局是 edits_数字 - 数字（数字是 19 位的，我这里画图写了 4 位），并且是递增的。

后面的文章说过，NameNode 重启的时候，就会加载 edits_inprogress、edits、以及 fsimage 这几个文件，因为这几个文件合起来就是残缺的元数据。因为 edits 会越来越多，所以就须要进行合并，进步启动的速度，然而 NameNode 的压力曾经很大了，所以须要 SecondaryNamenode 来做。
SecondaryNamenode 会隔一段时间就去申请 NameNode 获取 fsimage 和 edits 文件，如果两次 CheckPoint 的工夫曾经超过 1 个小时或者两次 CheckPoint 的操作记录曾经超过 10w 条，那 NameNode 就会生成一个空的 edits.new 文件，同时把 edits 文件以及 fsimage 文件发送给 SecondaryNamenode。

SecondaryNamenode 就会在本地把 edits 文件和 fsimage 文件进行合并，生成一个新的 fsimage.ckpt 文件。

生成后的 fsimage.ckpt 就会发给 NameNode，NameNode 就会把这个文件笼罩原来的 fsimage，fsimage_0006 此时前面的数字，对应着 edits_0001 到 edits_0006 的元数据汇合。此时就会把旧的 edits 删除，并且把 edits.new 文件重命名 edis 文件。
有时候咱们会看到 fsimage 会有两个，这个是为了最新 fsimage 不可用的时候，能回滚之前的元数据状态，当然新增的元数据就失落了。

集群

如果非集群的话，元数据的长久化是写入磁盘，如果是集群的话，元数据除了写入磁盘，还会写入 JournalNode。所以刚开始的时候，active 节点的 NameNode 和 JournalNode 的元数据是一样的。

standby 节点的 NameNode，每隔 60 秒，就会去 JournalNode 读取元数据信息。

当 CheckPoint 触发的时候，就会把 edits 文件和 fsimage 文件，合并生成新的 fsimage 文件。

而后 standby 节点的 NameNode 就会把新的 fsimage 发送给 active 节点的 NameNode。active 节点的 NameNode 替换旧的 fsimage，就会把 edits 文件删除。

至此，实现了 edits 文件和 fsimage 的合并。