HDFS SecondaryNameNode的checkpoint流程示意图

最新推荐文章于 2024-07-03 14:44:32 发布

原创

最新推荐文章于 2024-07-03 14:44:32 发布 · 395 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#hdfs #hadoop #big data

本文详细介绍了HDFS中NameNode的元数据管理，包括FsImage和Edits文件的作用，以及为何需要SecondaryNameNode进行checkpoint操作。当元数据更新时，Edits文件用于记录变化，而checkpoint过程则用于定期合并FsImage和Edits以防止数据丢失，确保系统的一致性和高效运行。

为什么需要checkpoint？

NN和2NN工作机制：

思考：NameNode中的元数据是存储在哪里的？

首先，我们做个假设，如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。

这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新FsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦NameNode节点断电，就会产生数据丢失。因此，引入Edits文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到Edits中。这样，一旦NameNode节点断电，可以通过FsImage和Edits的合并，合成元数据。

但是，如果长时间添加数据到Edits中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行FsImage和Edits的合并，如果这个操作由NameNode节点完成，又会效率过低。因此，引入一个新的节点SecondaryNamenode，专门用于FsImage和Edits的合并。

checkpoint示意图：