Hdfs(六)SecondaryNameNode

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

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

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

一、SecondaryNameNode介绍

Secondary NameNode名字给人感觉像是NameNode的备份，其实是冷备份。

NameNode

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

这里有两个不同的文件：

1、fsimage：它是在NameNode启动时，对整个文件系统的快照。

2、edit logs：它是在NameNode启动后，对文件系统的改动序列。

只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群（比如Ambari或ClouderManager）中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。

在这种情况下就会出现下面一些问题：

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

2、NameNode的重启会花费很长时间，因为有很多改动（在edit logs中）要合并到fsimage文件上。

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

NameNode职责是管理元数据信息，DataNode的职责是负责数据具体存储

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

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

Secondary NameNode

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

上图展示了Secondary NameNode是怎么工作的：

1、首先，它定时到NameNode去获取edit logs，并更新到fsimage上。（Secondary NameNode自己的fsimage）

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

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

Secondary NameNode的整个目的是在HDFS中提供一个检查点，它只是NameNode的一个助手节点，帮助NameNode更好的工作，这也是它在社区内被认为是检查点节点的原因。它不是要取代掉NameNode也不是NameNode的备份。所以从现在起，让我们养成一个习惯，称呼它为检查点节点吧。

重点：

1. SecondaryNameNode不是NameNode的热备份，但是SecondaryNameNode能够一定程度上对元数据做到备份，但不是全部 - SecondaryNameNode主要是负责edits_inprogress文件的滚动和fsimage文件的更新。

2. 在集群中，如果存在SecondaryNameNode，那么edits_inprogress文件的滚动和fsimage文件的更新是由SecondaryNameNode来完成；如果没有SecondaryNameNode，那么edits_inprogress文件的滚动和fsimage文件的更新就会由NameNode自己来完成。

3. 到目前为止，HDFS集群只支持两种结构：

a. 1个NameNode+1个SecondaryNameNode+n个DataNode。

b. n个NameNode(Hadoop2.X中是2个，Hadoop3.X中是n个，1个Active+多个Standby状态)+n个DataNode。

4. 在HDFS集群中，NameNode如果只有1个，那么NameNode宕机之后，整个集群就无法对外提供服务，所以必须对NameNode来进行备份，避免单点故障，所以在集群中，要考虑使用上述的第二种方案

总之：SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的edit logs到fsimage文件中。SecondaryNamenode根本就不是Namenode的一个热备，其只是将fsimage和edits合并。其拥有的fsimage不是最新的，因为在他从NameNode下载fsimage和edits文件时候，新的更新操作已经写到edit.new文件中去了。而这些更新在SecondaryNamenode是没有同步到的！当然，如果NameNode中的fsimage真的出问题了，还是可以用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage，虽然已经不是最新的fsimage，但是我们可以将损失减小到最少，帮助主要的NameNode执行Checkpoint操作，以提高HDFS的可靠性和性能。Secondary NameNode还可以帮助减轻NameNode的负载，通过压缩和清理Edit Log来减小其大小。这些功能使得HDFS能够更好地处理故障恢复和大量写入操作，从而提供更可靠和高效的分布式存储和处理解决方案。