zoukankan      html  css  js  c++  java
  • secondary namenode 检查点

     

    secondary namenode

    NameNode职责是管理元数据信息,DataNode的职责是负责数据具体存储,那么SecondaryNameNode的作用是什么?对很多初学者来说是非常迷惑的。它为什么会出现在HDFS中。从它的名字上看,它给人的感觉就像是NameNode的备份。但它实际上却不是。

    大家猜想一下,当HDFS集群运行一段事件后,就会出现下面一些问题:

    ledit logs文件会变的很大,怎么去管理这个文件是一个挑战。

    lNameNode重启会花费很长时间,因为有很多改动要合并到fsimage文件上。

    l如果NameNode挂掉了,那就丢失了一些改动。因为此时的fsimage文件非常旧。

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

    SecondaryNameNode就是来帮助解决上述问题的,它的职责是合并NameNodeedit logsfsimage文件中

     

     

    Checkpoint

    每达到触发条件,会由secondary namenodenamenode上积累的所有edits和一个最新的fsimage下载到本地,并加载到内存进行merge(这个过程称为checkpoint),如下图所示:

    Checkpoint详细步骤

    lNameNode管理着元数据信息,其中有两类持久化元数据文件:edits操作日志文件和fsimage元数据镜像文件。新的操作日志不会立即与fsimage进行合并,也不会刷到NameNode的内存中,而是会先写到edits(因为合并需要消耗大量的资源),操作成功之后更新至内存。

    ldfs.namenode.checkpoint.perioddfs.namenode.checkpoint.txns 两个配置,只要达到这两个条件任何一个,secondarynamenode就会执行checkpoint的操作。

    l当触发checkpoint操作时,NameNode会生成一个新的edits即上图中的edits.new文件,同时SecondaryNameNode会将edits文件和fsimage复制到本地(HTTP GET方式)。

    lsecondarynamenode将下载下来的fsimage载入到内存,然后一条一条地执行edits文件中的各项更新操作,使得内存中的fsimage保存最新,这个过程就是editsfsimage文件合并,生成一个新的fsimage文件即上图中的Fsimage.ckpt文件。

    lsecondarynamenode将新生成的Fsimage.ckpt文件复制到NameNode节点。

    lNameNode节点的edits.new文件和Fsimage.ckpt文件会替换掉原来的edits文件和fsimage文件,至此刚好是一个轮回,即在NameNode中又是editsfsimage文件。

    l等待下一次checkpoint触发SecondaryNameNode进行工作,一直这样循环操作。

     Checkpoint触发条件

    Checkpoint操作受两个参数控制,可以通过core-site.xml进行配置:

    <property>

      <name> dfs.namenode.checkpoint.period</name>

       <value>3600</value>

        <description>

    两次连续的checkpoint之间的时间间隔。默认1小时

    </description>

    </property>

    <property>

      <name>dfs.namenode.checkpoint.txns</name>

      <value>1000000</value>

      <description>

    最大的没有执行checkpoint事务的数量,满足将强制执行紧急checkpoint,即使尚未达到检查点周期。默认设置为100万。

    </description>

    </property>

    从上面的描述我们可以看出,SecondaryNamenode根本就不是Namenode的一个热备,其只是将fsimageedits合并。其拥有的fsimage不是最新的,因为在他从NameNode下载fsimageedits文件时候,新的更新操作已经写到edit.new文件中去了。而这些更新在SecondaryNamenode是没有同步到的!当然,如果NameNode中的fsimage真的出问题了,还是可以用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage,虽然已经不是最新的fsimage,但是我们可以将损失减小到最少!



  • 相关阅读:
    linux下安装mysql
    简单理解:使用linux的ip地址访问Java项目
    上传项目到github完整步骤及如何删除项目
    解决service iptables save出错please try to use systemctl.
    PCI1255信号采集板卡的干扰来源和解决办法
    L298N驱动的再利用
    千里狼-高速采集相机试用记录
    调试研华PCI1245E记录
    超大型的迷宫
    labview实现模拟python微信模块
  • 原文地址:https://www.cnblogs.com/TiePiHeTao/p/8890dcdcc9d89972e4f4f93a989b9cef.html
Copyright © 2011-2022 走看看