模块系统深度实战作用.pdfVIP

SecondaryNameNode作用

在Hadoop中，有一些命名不好的模块，SecondaryNameNode是其中之一。从它

的名字上看，它给人的感觉就像是NameNode的备份。但它实际上却不是。很多Hadoop

的初学者都很疑惑，SecondaryNameNode究竟是做什么的，而且它为什么会出现在HDFS

中。本文将解释下SecondaryNameNode在HDFS中所扮演的角色。

从它的名字来看，你可能认为它跟NameNode有点关系。没错，你猜对了。因此在我

们深入了解SecondaryNameNode之前，我们先来看看NameNode是做什么的。

NameNode

NameNode主要是用来保存HDFS的元数据信息，比如命名空间信息，块信息等。当它

运行的时候，这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。

上面的这张展示了NameNode怎么把元数据保存到磁盘上的。这里有两个不同的

文件：

fsimage-它是在NameNode启动时对整个文件系统的快照

editlogs-它是在NameNode启动后，对文件系统的改动序列

只有在NameNode重启时，editlogs才会合并到fsimage文件中，从而得到一个

文件系统的快照。但是在产品集群中NameNode是很少重启的，这也意味着当

NameNode运行了很长时间后，editlogs文件会变得很大。在这种情况下就会出现下面

一些问题：

1.editlogs文件会变的很大，怎么去管理这个文件是一个。

2.NameNode的重启会花费很长时间，因为有很多改动[在editlogs中]要合并到

fsimage文件上。

3.如果NameNode挂掉了，那我们就丢失了很多改动因为此时的fsimage文件非常旧。

[在这个情况下丢失的改动不会很多,因为丢失的改动应该是还在内存中但是没有写

到editlogs的这部分。]

因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小editlogs文

件的大小和得到一个的fsimage文件，这样也会减小在NameNode上的。

现在我们明白了NameNode的功能和所的-保持文件系统的元数据。

那么，这些跟SecondaryNameNode又有什么关系呢？

[

叶子备注：

那么从上面的分析以及后面的文档可以知道，或者说，很容易产生一个疑问，既然fsimage

要在nameNode重启以后才能更新，即便后面有了secondaryNameNode也要一定

的时间后才会去同步这些文件，那么为什么每次上传一个文件后，就可以马上通过命令行方

式获取到这个文件呢，我的元数据信息可是保存在fsimage中的呀记了，fsimage

和edit的存在只是为了持久化这些数据信息，这意味着，nameNode启动，内存当中

肯定也是保存着这些信息的，而添加删除文件等操作所产生的信息，肯定也是有保存到

nameNode的内存当中的（不然怎么可能马上就到这些数据呢），同步fsimage，合

并edit，只是为了持久化这些数据，防止nameNode出现异常时元数据信息的丢失。

]

SecondaryNameNode

SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的

editlogs到fsimage文件中。

上面的展示了SecondaryNameNode是怎么工作的。

首先，它定时到NameNode去获取editlogs，并更新到fsimage上。[Secondary

NameNode自己的fsimage]

一旦它有了新的fsimage文件，它将其拷贝回NameNode中。