Secondary NameNode:它究竟有什么作用？

前言

最近刚接触Hadoop, 一直没有弄明白NameNode和Secondary NameNode的区别和关系。很多人都认为，Secondary NameNode是NameNode的备份，是为了防止NameNode的单点失败的，直到读了这篇文章Secondary Namenode - What it really do? (需翻墙)才发现并不是这样。文章写的很通俗易懂，现将其翻译如下：

Secondary NameNode:它究竟有什么作用？

在Hadoop中，有一些命名不好的模块，Secondary NameNode是其中之一。从它的名字上看，它给人的感觉就像是NameNode的备份。但它实际上却不是。很多Hadoop的初学者都很疑惑，Secondary NameNode究竟是做什么的，而且它为什么会出现在HDFS中。因此，在这篇文章中，我想要解释下Secondary NameNode在HDFS中所扮演的角色。

从它的名字来看，你可能认为它跟NameNode有点关系。没错，你猜对了。因此在我们深入了解Secondary NameNode之前，我们先来看看NameNode是做什么的。

NameNode

NameNode主要是用来保存HDFS的元数据信息，比如命名空间信息，块信息等。当它运行的时候，这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。

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

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

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

只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。在这种情况下就会出现下面一些问题：

edit logs文件会变的很大，怎么去管理这个文件是一个挑战。

NameNode的重启会花费很长时间，因为有很多改动[笔者注:在edit logs中]要合并到fsimage文件上。

如果NameNode挂掉了，那我们就丢失了很多改动因为此时的fsimage文件非常旧。[笔者注: 笔者认为在这个情况下丢失的改动不会很多, 因为丢失的改动应该是还在内存中但是没有写到edit logs的这部分。]

因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。这跟Windows的恢复点是非常像的，Windows的恢复点机制允许我们对OS进行快照，这样当系统发生问题时，我们能够回滚到最新的一次恢复点上。

现在我们明白了NameNode的功能和所面临的挑战 - 保持文件系统最新的元数据。那么，这些跟Secondary NameNode又有什么关系呢？

Secondary NameNode

SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的edit logs到fsimage文件中。

上面的图片展示了Secondary NameNode是怎么工作的。

首先，它定时到NameNode去获取edit logs，并更新到fsimage上。[笔者注：Secondary NameNode自己的fsimage]

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

NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间。

Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的原因。

现在，我们明白了Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。所以从现在起，让我们养成一个习惯，称呼它为检查点节点吧。

—————————————仔细阅读下面最精彩————————————————

浅析 Secondary NameNode(辅助namenode)

在初学Hadoop时，有个让人疑惑的概念：Secondary NameNode，也叫辅助namenode。从命名看，好像是第二个namenode，用于备份主namenode，在主namenode失败后启动。那么，Secondary NameNode的作用是什么？是如何工作的？

一，NameNode

HDFS集群有两类节点以管理者和工作者的工作模式运行，namenode就是其中的管理者。它管理着文件系统的命名空间，维护着文件系统树及整棵树的所有文件和目录。这些信息以两个文件的形式保存于内存或者磁盘，这两个文件是：命名空间镜像文件fsimage和编辑日志文件edit logs ，同时namenode也记录着每个文件中各个块所在的数据节点信息。

namenode对元数据的操作过程

图中有两个文件：

（1）fsimage:文件系统映射文件，也是元数据的镜像文件（磁盘中），存储某段时间namenode内存元数据信息。

（2）edits log:操作日志文件。

这种工作方式的特点：

（1）namenode始终在内存中存储元数据（metedata）,使得“读操作”更加快、

（2）有“写请求”时，向edits文件写入日志，成功返回后才修改内存，并向客户端返回。

（3）fsimage文件为metedata的镜像，不会随时同步，与edits合并生成新的fsimage。

从以上特点可以知道，edits文件会在集群运行的过程中不断增多，占用更多的存储空间，虽然有合并，但是只有在namenode重启时才会进行。并且在实际工作环境很少重启namenode，

这就带来了一下问题：

（1）edits文件不断增大，如何存储和管理？

（2）因为需要合并大量的edits文件生成fsimage，导致namenode重启时间过长。

（3）一旦namenode宕机，用于恢复的fsiamge数据很旧，会造成大量数据的丢失。

二，Secondary NameNode

上述问题的解决方案就是运行辅助namenode–Secondary NameNode，为主namenode内存中的文件系统元数据创建检查点，Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份，

SecondaryNameNode有两个作用，一是镜像备份，二是日志与镜像的定期合并。两个过程同时进行，称为checkpoint（检查点）。

镜像备份的作用：备份fsimage(fsimage是元数据发送检查点时写入文件)；

日志与镜像的定期合并的作用：将Namenode中edits日志和fsimage合并,防止如果Namenode节点故障，namenode下次启动的时候，会把fsimage加载到内存中，应用edits log,edits log往往很大，导致操作往往很耗时。（这也是namenode容错的一套机制）

Secondary NameNode创建检查点过程

Secondarynamenode工作过程

（1）SecondaryNameNode通知NameNode准备提交edits文件，此时主节点将新的写操作数据记录到一个新的文件edits.new中。

（2）SecondaryNameNode通过HTTP GET方式获取NameNode的fsimage与edits文件（在SecondaryNameNode的current同级目录下可见到 temp.check-point或者previous-checkpoint目录，这些目录中存储着从namenode拷贝来的镜像文件）。

（3）SecondaryNameNode开始合并获取的上述两个文件，产生一个新的fsimage文件fsimage.ckpt。

（4）SecondaryNameNode用HTTP POST方式发送fsimage.ckpt至NameNode。

（5）NameNode将fsimage.ckpt与edits.new文件分别重命名为fsimage与edits，然后更新fstime，整个checkpoint过程到此结束。

SecondaryNameNode备份由三个参数控制fs.checkpoint.period控制周期（以秒为单位，默认3600秒），fs.checkpoint.size控制日志文件超过多少大小时合并（以字节为单位，默认64M）， dfs.http.address表示http地址，这个参数在SecondaryNameNode为单独节点时需要设置。

从工作过程可以看出，SecondaryNameNode的重要作用是定期通过编辑日志文件合并命名空间镜像，以防止编辑日志文件过大。SecondaryNameNode一般要在另一台机器上运行，因为它需要占用大量的CPU时间与namenode相同容量的内存才可以进行合并操作。它会保存合并后的命名空间镜像的副本，并在namenode发生故障时启用。

--------------------- 

作者：小飞001 

来源：CSDN 

原文：https://blog.csdn.net/qq_43617838/article/details/85012688