Secondary NameNode:的作用--转载

最新推荐文章于 2021-05-27 22:37:38 发布

zuoseve01

最新推荐文章于 2021-05-27 22:37:38 发布

阅读量260

点赞数

分类专栏： hadoop

原文链接：https://blog.csdn.net/u013411339/article/details/105548660，https://www.jianshu.com/p/5d292a9a8c86

版权

hadoop 专栏收录该内容

11 篇文章 2 订阅

订阅专栏

文章一

前言

最近刚接触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是什么时候将改动写到edit logs中的？这个操作实际上是由DataNode的写操作触发的，当我们往DataNode写文件时，DataNode会跟NameNode通信，告诉NameNode什么文件的第几个block放在它那里，NameNode这个时候会将这些元数据信息写到edit logs文件中。

9人点赞

大数据

作者：可文分身
链接：https://www.jianshu.com/p/5d292a9a8c86
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

文章二

前言

HDFS SecondaryNameNode是干什么的？

这是道经典的基础面试题，笔者问过面试者很多次（当然也被面试官问过很多次）。从印象看，大约有一半的被面试者无法正确作答，给出的答案甚至有“不就是NameNode的热备嘛”。本文来简单聊聊相关的知识，为节省篇幅，将SecondaryNameNode简称SNN，NameNode简称NN。

NN与fsimage、edits文件

NN负责管理HDFS中所有的元数据，包括但不限于文件/目录结构、文件权限、块ID/大小/数量、副本策略等等。客户端执行读写操作前，先从NN获得元数据。当NN在运行时，元数据都是保存在内存中，以保证响应时间。

显然，元数据只保留在内存中是非常不可靠的，所以也需要持久化到磁盘。NN内部有两类文件用于持久化元数据：

fsimage文件，以fsimage_为前缀，是序列化存储的元数据的整体快照；
edits文件（又称edit log），以edits_为前缀，是顺序存储的元数据的增量修改（即客户端写入操作）日志。

这两类文件均存储在${dfs.namenode.name.dir}/current/路径下，如下图所示。

可见，当前正在写入的edits文件名会有"inprogress"标识，而seen_txid文件保存的就是当前正在写入的edits文件的ID。

在任意时刻，最近的fsimage和edits文件的内容加起来就是全量元数据。NN在启动时，就会将最近的fsimage文件加载到内存，并重放它之后记录的edits文件，恢复元数据的现场。

SNN与checkpoint过程

为了避免edits文件过大，以及缩短NN启动时恢复元数据的时间，我们需要定期地将edits文件合并到fsimage文件，该合并过程叫做checkpoint（这个词是真正被用烂了哈）。

由于NN的负担已经比较重，再让它来进行I/O密集型的文件合并操作就不太科学了，所以Hadoop引入了SNN负责这件事。也就是说，SNN是辅助NN进行checkpoint操作的角色。

checkpoint的触发由hdfs-site.xml中的两个参数来控制。

dfs.namenode.checkpoint.period：触发checkpoint的周期长度，默认为1小时。
dfs.namenode.checkpoint.txns：两次checkpoint之间最大允许进行的操作数，默认为100万。

只要满足上述两个参数的条件之一，就会触发checkpoint过程，叙述如下：

NN生成新的edits_inprogress文件，后续的修改日志将写入该文件中，之前正在写的edits文件即为待合并状态。
将待合并的edits文件和fsimage文件一起复制到SNN本地。
SNN像NN启动时一样，将fsimage文件加载到内存，并重放edits文件进行合并。生成合并结果为fsimage.chkpoint文件。
SNN将fsimage.chkpoint复制回NN，并重命名为正式的fsimage文件名。

Hadoop官方给出的图示如下。虽然文件名称不同，但思想是一样的。

如果开启了NN高可用呢？

上面说的都是集群只有一个NN的情况。如果有两个NN并且开启了HA的话，SNN就没用了——checkpoint过程会直接交给Standby NN来负责。Active NN会将edits文件同时写到本地与共享存储（QJM方案就是JournalNode集群）上去，Standby NN从JournalNode集群拉取edits文件进行合并，并保持fsimage文件与Active NN的同步。