Namenode和Secondarynamenode的关系

我需要了解hadoop集群中的两个进程
secondary namenode和namenode的区别
在Hadoop中，有一些命名不好的模块，Secondary NameNode是其中之一。

Secondary NameNode是NameNode的备份，是为了防止NameNode的单点失败的。

但其实不是，但是也是跟namenode有关系的。

我们主要了解Secondary NameNode在HDFS中所扮演的角色。

 

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

NameNode存储元数据流程图
 

上图我们看到了NameNode如何把元数据保存到磁盘上的。这里有两个不同的文件：

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

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

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

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

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

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

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

 

现在需要解决这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。

这跟Windows的恢复点是非常像的，Windows的恢复点机制允许我们对OS进行快照，这样当系统发生问题时，我们能够回滚到最新的一次恢复点上。

现在我们知道了NameNode的功能和所面临的挑战 - 保持文件系统最新的元数据。

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

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

Secondary NameNode简单的工作流程图

上图我们看到了Secondary NameNode是怎样工作的。

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

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

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

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

5. 现在，我们明白了Secondary NameNode所做的不过是在文件系统中设置一个检查点来辅助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。所以Secondary NameNode称为检查点节点。

 

NameNode何时写到edit log中
NameNode是什么时候将改动写到edit logs中的？

这个步骤，实际上是由DataNode的写操作触发的，当我们往DataNode写文件时，DataNode会跟NameNode通信，告诉NameNode什么文件的第几个block放在它那里，NameNode这个时候会将这些元数据信息写到edit logs文件中。

 

其他博客对这个机制的讲解

namenode和secondnamenode的通信原理：

Namenode主要维护两个文件，一个是fsimage，一个是editlog。 
fsimage保存了最新的元数据检查点，包含了整个HDFS文件系统的所有目录和文件的信息。对于文件来说包括了数据块描述信息、修改时间、访问时间等；对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。 
editlog主要是在NameNode已经启动情况下对HDFS进行的各种更新操作进行记录，HDFS客户端执行所有的写操作都会被记录到editlog中。

简单来想，NameNode维护了文件与数据块的映射表以及数据块与数据节点的映射表。 
就是一个文件，它切分成了几个数据块，以及这些数据块分别存储在哪些datanode上，namenode一清二楚。Fsimage就是在某一时刻，整个hdfs 的快照，就是这个时刻hdfs上所有的文件块和目录，分别的状态，位于哪些个datanode，各自的权限，各自的副本个数。然后客户端对hdfs所有的更新操作，比如说移动数据，或者删除数据，都会记录在editlog中。 
为了避免editlog不断增大，secondary namenode会周期性合并fsimage和edits成新的fsimage，新的操作记录会写入新的editlog中，这个周期可以自己设置（editlog到达一定大小或者定时）。

详细步骤： 
第一步：将hdfs更新记录写入一个新的文件——edits.new。 
第二步：将fsimage和editlog通过http协议发送至secondary namenode。 
第三步：将fsimage与editlog合并，生成一个新的文件——fsimage.ckpt。这步之所以要在secondary namenode中进行，是因为比较耗时，如果在namenode中进行，或导致整个系统卡顿。 
第四步：将生成的fsimage.ckpt通过http协议发送至namenode。 
第五步：重命名fsimage.ckpt为fsimage，edits.new为edits。 
第六步：fsimage与editlog合并的过程就完成了。

如果namenode宕机，其实secondary namenode还保存这一份不久前的fsimage，还能挽回一些损失吧。一旦有datanode挂掉了（宕机或者是网络阻塞），namenode能很快感知到，并且将宕机的节点上的数据块转移至其余空闲节点。这点是因为hdfs中心跳机制（heartbeat）。心跳机制默认3s中一次，datanode会向namenode发送一次心跳，告知namenode当前节点上存放的数据文件是什么。如果namenode中记录的是该datanode存放了文件A的两个数据块和文件B的一个数据块，但是心跳中只有文件A的二个数据块信息，namenode就会知道该datanode数据块损坏了，会把损坏的数据块在别的datanode上补充。