Hadoop中SecondaryNameNode工作机制

桃扇骨 2022-05-28 01:57 235阅读 0赞

SecondaryNameNode是一个用来监控HDFS状态的辅助后台程序，部署在一个单独的服务器上。与NameNode进行通信，以便定期地保存HDFS元数据的快照（周期性将Edits日志文件与fsimage进行合并）。由于NameNode是单点的，通过SecondaryNameNode快照功能，可将NameNode宕机时间和数据损失降低到最小。

**SecondaryNameNode产生原因**  
Hadoop文件系统会出现编辑日志不断增长的情况。尽管在NameNode运行期间不会对系统造成影响，但是如果NameNode重新启动，它将会花费很长时间运行编辑日志中的每个操作。在此期间（即安全模式时间），文件系统还是不可用的，通常来说这是不符合应用需求的。为了解决这个问题，在NameNode之外的节点上运行一个SecondaryNameNode进程，为NemeNode内存中的文件系统元数据产生检查点（辅助NameNode处理fsimage和edits）。这样周期性的合并就能减少重启的时间。同时也能保证HDFS系统的数据完整性。

**Secondary NameNode不足之处**

1.  SecondaryNameNode保存的只是Checkpoint时刻的元数据  
    一旦NameNode上元数据损坏，通过SNN恢复的元数据并不是HDFS此刻的最新数据，存在一致性问题。
2.  没有做到热备，当NameNode无法提供服务时，需要重启NameNode，服务恢复时间与文件系统规模大小成正比。

为了解决以上问题，从Hadoop2.0开始，引入了高可用HA机制

**将SNN进程运行在一台非NameNode的机器上的原因**

可扩展性：创建一个新的HDFS的快照需要将namenode中加载到内存的metadata信息全部拷贝一遍，这样的操作需要的内存就需要和namenode占用的内存一样，由于分配给namenode进程的内存其实是对HDFS文件系统的限制，如果分布式文件系统非常的大，那么 namenode那台机器的内存就可能会被全部占据。

容错性：当snn创建一个checkpoint的时候，它会将checkpoint拷贝成metadata的几个拷贝。将这个操作运行到另外一台机器，还可以提供分布式文件系统的容错性。

**checkpoint工作机制**

1.  当edits文件的大小64M或者间隔1小时时checkpoint会触发SecondaryNameNode进行工作
2.  当触发一个checkpoint操作时，辅助Namenode请求主Namenode停止使用edits文件  
    暂时将新的写操作记录到一个临时文件中edits.new
3.  SecondaryNameNode将edits文件和fsimage复制到本地（采用HTTP GET）
4.  SecondaryNameNode将fsimage文件载入到内存，逐一执行edits文件中的操作，从而生成新的fsimage文件
5.  SecondaryNameNode将新的fsimage文件发送回Namenode（使用HTTP POST）
6.  Namenode节点将接收的fsimage文件替换旧的fsimage文件，edits.new文件替换旧的edits文件（即改名）  
    同时更新VERSION版本和fstime文件来记录检查点执行的时间

尽管读取FsImage是有效的，但是在FsImage文件后附加是无效的。 相对于修改FsImage，更建议修改EditLog文件。在执行校验点的过程中就是把EditLog转换到FsImage中的过程。

校验点的目的：通过把hdfs文件系统元数据的快照保存到FsImage中从而保持了hdfs文件系统的一致性。

校验点触发方式：

1.  根据时间循环(dfs.namenode.checkpoint.period)单位是秒触发：1小时
2.  根据文件系统的事务增加量(dfs.namenode.checkpoint.txns)触发：64M  
    如果两个都进行了设置，那么哪个先达到了，就会触发校验点。

![这里写图片描述][70]

**SNN checkpoint配置**

可以在core-site.xml文件中进行配置，如下：

<property>  
      <name>fs.checkpoint.period</name>  
      <value>3600</value>  
      <description>The number of seconds between two periodic checkpoints.  
      </description>  
    </property>  
    <property>  
      <name>fs.checkpoint.size</name>  
      <value>67108864</value>  
      <description>The size of the current edit log (in bytes) that triggers  
           a periodic checkpoint even if the fs.checkpoint.period hasn't expired.  
      </description>  
    </property>

Secondary NameNode的检查点进程启动，是由以下两个配置参数控制的:  
（1）fs.checkpoint.period指定连续两次检查点的最大时间间隔。默认值是1小时。  
（2）fs.checkpoint.size定义了日志文件的最大值，一旦超过这个值会导致强制执行检查点。默认值是64MB。

**SNN文件结构**

SecondaryNamenode在每次处理过程结束后都有一个检查点  
这个检查点可以在一个子目录 /previous.checkpoint中找到，可以作为NameNode的元数据备份源，目录如下：

$ {fs.checkpoint.dir}/current/VERSION
    $ {fs.checkpoint.dir}/current/edits
    $ {fs.checkpoint.dir}/current/fsimage
    $ {fs.checkpoint.dir}/current/fstime
    $ {fs.checkpoint.dir}/previous.checkpoint/VERSION           
    $ {fs.checkpoint.dir}/previous.checkpoint/edits
    $ {fs.checkpoint.dir}/previous.checkpoint/fsimage
    $ {fs.checkpoint.dir}/previous.checkpoint/fstime

以上目录和NameNode的/current目录结构是完全相同的，这样设计的目的是：万一NameNode发生故障，并且没有用于恢复的备份，甚至NFS中也没有备份，就可以直接从SecondaryNamenode恢复。

[70]: /images/20220528/a15047d8113d41e7a44df76ac2a02050.png