SecondaryNameNode：第二名称节点.docxVIP

SecondaryNameNode SecondaryNameNode:第二名称节点 前言最近刚接触 Hadoop, 一直没有弄明白 NameNode 和 Secondary NameNode 的区别和关系。很多人都认为， Secondary NameNode 是 NameNode 的备份，是为了防止 NameNode 的单点失败的，直到读了这篇文章 Secondary Namenode - What it really do? （ 需翻墙）才发现并不是这样。 文 章写的很通俗易懂， 现将其翻译如下: Secondary NameNode: 它究竟有什么作用？在 Hadoop 它究竟有什么作用？在 Hadoop 中，有一些命名不好的模块， Secondary NameNode 是其中之一。 从它的名字上看， 它给人 的感觉就像是 NameNode 的备份。但它实际上却不是。很多 中。因此，在这篇文Hadoop 的初学者都很疑惑， Secondary NameNode 究竟是做 什么的，而且它为什么会出现在 HDFS 中。因此，在这篇文 章中，我想要解释下 Secondary NameNode 在 HDFS 中所扮 演的角色。从它的名字来看，你可能认为它跟 NameNode 有 点关系。没错，你猜对了。因此在我们深入了解Secondary 点关系。没错，你猜对了。因此在我们深入了解 Secondary NameNode 之前，我们先来看看 NameNode 是做什么的 NameNodeNameNode 主要是用来保存 HDFS 的元数据信息， 比如命名空间信息，块信息等。当它运行的时候，这些信息 是存在内存中的。但是这些信息也可以持久化到磁盘上。上 面的这张图片展示了 NameNode 怎么把元数据保存到磁盘上 的。这里有两个不同的文件: fsimage - 它是在 NameNode 启 动时对整个文件系统的快照 edit logs - 它是在 NameNode 启 动后，对文件系统的改动序列只有在 NameNode 重启时， edit NameNode 是很少重启的，这logs 才会合并到 fsimage NameNode 是很少重启的，这 也意味着当 NameNode 运行了很长时间后， edit logs 文件会 变得很大。在这种情况下就会出现下面一些问题：edit logs 变得很大。在这种情况下就会出现下面一些问题： edit logs 文件会变的很大，怎么去管理这个文件是一个挑战 NameNode 的重启会花费很长时间， 因为有很多改动 ［ 笔者注 : 在 edit logs 中 ］要合并到 fsimage 文件上。如果 NameNode 挂 掉了，那我们就丢失了很多改动因为此时的 fsimage 文件非 常旧。［笔者注 : 笔者认为在这个情况下丢失的改动不会很多 因为丢失的改动应该是还在内存中但是没有写到edit logs 因为丢失的改动应该是还在内存中但是没有写到 edit logs 的 这部分。 ］因此为了克服这个问题， 我们需要一个易于管理的 机制来帮助我们减小 edit logs 文件的大小和得到一个最新的 fsimage 文件，这样也会减小在 NameNode 上的压力。这跟 Windows 的恢复点是非常像的， Windows 的恢复点机制允许 我们对 OS 进行快照，这样当系统发生问题时，我们能够回 能和所面临的挑战 - 保持文件系统最新的元数据。 那么， 这 些跟 Secondary NameNode 又有什么关系呢？ Secondary 滚到最新的一次恢复点上。现在我们明白了NameNode 滚到最新的一次恢复点上。现在我们明白了 NameNode 的功 NameNodeSecondaryNameNode 就是来帮助解决上述问题的， 它的职责是合并 NameNode 的 edit logs 到 fsimage 文件中。 上面的图片展示了 Secondary NameNode 是怎么工作的。首 先，它定时到 NameNode 去获取 edit logs ，并更新到 fsimage 。NameNode。[笔者注： Secondary NameNode 自己的 fsimage] 一旦它有 了新的fsimage文件，它将其拷贝回 NameNode 。NameNode 在下次重启时会使用这个新的 fsimage 文件，从而减少重启 的时间。Secondary NameNode的整个目的是在 HDFS中提供 个检查点。它只是 NameNode 的一个助手节点。这也是它 在社区内被认为是检查点节点的原因。现在，我们明白了 Secondary NameNode 所做的不过是在文件系统中设置一个 检查点来帮