SecondaryNameNode与Hadoop高可用（HA）的区别_hadoop高可用有sencondnamenode-CSDN博客

本文链接：https://blog.csdn.net/weixin_52918377/article/details/116534527

一、SecondaryNameNode介绍

要了解Secondary NameNode之前，我们先来看看NameNode是做什么的。

NameNode

NameNode：主要用来保存HDFS的元数据信息，比如命名空间信息，块信息等。当它运行的时候，这些信息在内存，也可以持久化到磁盘上。如果存储在NameNode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断电，元数据丢失，整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。

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

fsimage 与edit logs

这里有两个不同的文件：

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

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

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

Secondary NameNode

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

在这里插入图片描述

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

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

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

当nameNode发生故障时，可以借助Secondary NameNode进行元数据恢复：

方法一：将SecondaryNameNode中数据拷贝到NameNode存储数据的目录
方法二：使用-importCheckpoint选项启动NameNode守护进程，从而将SecondaryNameNode中数据拷贝到NameNode目录中

所以一定程度上起到了元数据备份的作用。

总之，Secondary NameNode定期合并 fsimage和 edit logs，较少了namenode启动时间，一定程度上起到了元数据备份的作用。

二、HA（高可用）介绍

元数据同步

Hadoop2.0的HA 机制有两个NameNode，一个是Active状态，另一个是Standby状态。两者的状态可以切换，但同时最多只有1个是Active状态。只有Active Namenode提供对外的服务。Active NameNode和Standby NameNode之间通过NFS或者JN（JournalNode，QJM方式）来同步数据。

Active NameNode会把最近的操作记录写到本地的一个edits文件中（edits file），并传输到NFS或者JN中。Standby NameNode定期的检查，从NFS或者JN把最近的edit文件读过来，然后把edits文件和fsimage文件合并成一个新的fsimage，合并完成之后会通知Active NameNode获取这个新fsimage。Active NameNode获得这个新的fsimage文件之后，替换原来旧的fsimage文件。

这样，保持了Active NameNode和Standby NameNode的数据实时同步，Standby NameNode可以随时切换成Active NameNode（譬如Active NameNode挂了）。而且还有一个原来Hadoop1.0的SecondaryNameNode，CheckpointNode，BackupNode的功能：合并edits文件和fsimage文件，使fsimage文件一直保持更新。所以启动了hadoop2.0的HA机制之后，SecondaryNameNode，CheckpointNode，BackupNode这些都不需要了。

数据同步方式：NFS与 QJM（Quorum Journal Manager ）

1、NFS（会有数据同步问题）

NFS作为Active NameNode和Standby NameNode之间数据共享的存储。Active NameNode会把最近的edits文件写到NFS，而Standby NameNode从NFS中把数据读过来。这个方式的缺点是，如果Active NameNode或者Standby Namenode有一个和NFS之间网络有问题，则会造成他们之前数据的同步出问题。

2、 QJM（Quorum Journal Manager ）

QJM的方式可以解决上述NFS容错机制不足的问题。Active NameNode和Standby NameNode之间是通过一组JournalNode（数量是奇数，可以是3,5,7…,2n+1）来共享数据。Active NameNode把最近的edits文件写到2n+1个JournalNode上，只要有n+1个写入成功就认为这次写入操作成功了，然后Standby NameNode就可以从JournalNode上读取了。可以看到，QJM方式有容错机制，可以容忍n个JournalNode的失败。

在这里插入图片描述

Active和Standby两个NameNode之间的数据交互流程为：

NameNode在启动后，会先加载FSImage文件和共享目录上的EditLog Segment文件；
Standby NameNode会启动EditLogTailer线程和StandbyCheckpointer线程，正式进入Standby模式；
Active NameNode把EditLog提交到JournalNode集群；
Standby NameNode上的EditLogTailer 线程定时从JournalNode集群上同步EditLog；
Standby NameNode上的StandbyCheckpointer线程定时进行Checkpoint，并将Checkpoint之后的FSImage文件上传到Active NameNode。

主备NameNode切换

Active NameNode和Standby NameNode可以随时切换，可以人工和自动。人工切换是通过执行HA管理命令来改变NameNode的状态，从Standby到Active，或从Active到Standby。自动切换则在Active NameNode挂掉的时候，Standby NameNode自动切换成Active状态。

主备NameNode的自动切换需要配置Zookeeper。Active NameNode和Standby NameNode把他们的状态实时记录到Zookeeper中，Zookeeper监视他们的状态变化。当Zookeeper发现Active NameNode挂掉后，会自动把Standby NameNode切换成Active NameNode。

eeper监视他们的状态变化。当Zookeeper发现Active NameNode挂掉后，会自动把Standby NameNode切换成Active NameNode。

有关NameNode数据同步和主从切换的详细原理请查看我转载的另一篇文章
https://blog.csdn.net/weixin_52918377/article/details/116530772

参考文章
https://blog.csdn.net/andyguan01_2/article/details/88696239