Hadoop中SecondaryNameNode工作机制

最新推荐文章于 2023-03-23 08:57:28 发布

雾幻

最新推荐文章于 2023-03-23 08:57:28 发布

阅读量939

点赞数

分类专栏： hadoop 文章标签： hadoop SecondaryNameNode checkpoint

本文链接：https://blog.csdn.net/lb812913059/article/details/79717558

版权

hadoop 专栏收录该内容

36 篇文章 6 订阅

订阅专栏

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

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

Secondary NameNode不足之处

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

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

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

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

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

checkpoint工作机制

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

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

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

校验点触发方式：

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

这里写图片描述

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恢复。