NameNode 的所有操作及整个集群的状态都存储在 元数据 中，元数据通过 FSImage 和 Edits 文件保存。

【辅助理解】NameNode 的元数据存储在哪里？ 假设：如果元数据存储在 NameNode 节点的磁盘中，由于需要频繁地随机访问，还要响应客户请求，效率会很低。因此元数据需要放在内存中。 但如果只存到内存中，一旦机器断电，元数据就会丢失，整个集群就无法工作了。 —— 因此需要在磁盘中备份元数据的 FSImage。

【 新问题】内存中的元数据更新时，如果同时更新 FSImage，效率会很低，但如果不更新 FSImage，就容易出现一致性问题，一旦 NameNode 断电，就会丢失数据。 —— 因此引入 Edits 文件（只追加，效率很高），每当元数据需要添加或更新时，既修改内存中的元数据，并追加到 Edits 文件中。 —— 即使 NameNode 节点断电，也可以通过 FSImage 和 Edits 的合并，合成元数据。

它们的主要作用是：在集群启动时将集群的状态恢复到关闭前的状态。

—— 也就是 Hadoop 集群因为各种原因需要重新启动，元数据能保证集群启动之后的状态和上次停止前的状态一致。

第一次启动 NameNode 前的格式化（hdfs namenode -format）操作会创建 fsimage 和 edits 文件。

非第一次启动，NameNode 会进行数据恢复：首先把 fsimage 加载到内存中形成文件系统镜像，然后再把 edits 中 fsimage_txid 之后的、所有事务 回放到这个文件系统镜像上。这个时候，集群也就恢复到关闭前的状态了。

它们的位置需要在 hdfs-site.xml 文件中指定：

上面配置的2个条件，如果有任意一个满足了，就会触发 SecondaryNameNode 合并 FSImage 和 EditLog，具体流程为：

1）SecondaryNameNode 通知 NameNode 停止使用 EditLog，暂时将新的写操作存放到 edits.new 文件；

2）SecondaryNameNode 通过 HTTP GET 请求，从 NameNode 中获取 FSImage 和 EditLog，将它们加载到自己的内存中；

3）SecondaryNameNode 合并 FSImage 和 EditLog，合并完成后生成新的 FSImage，命名为 fsimage.ckpt；

4）SecondaryNameNode 通过 HTTP POST 请求方式，将新的 fsimage.ckpt 发送给 NameNode；

5）NameNode 把 fsimage.ckpt 改为 fsimage（覆盖掉原来的），并删掉旧的 edits 文件，把 edits.new 重命名为 edits，最后更新 fstime（即最后一个检查点的时间戳）。

通过这一系列操作，就避免了 edits 日志的无限增长，加快 Namenode 的启动过程。

NameNode原数据及checkpoint分析

作者：瘦风(https://healchow.com)

出处：博客园-瘦风的南墙(https://www.cnblogs.com/shoufeng)

感谢阅读，公众号 「瘦风的南墙」 ，手机端阅读更佳，还有其他福利和心得输出，欢迎扫码关注🤝

本文版权归博主所有，欢迎转载，但 [必须在页面明显位置标明原文链接]，否则博主保留追究相关人士法律责任的权利。