hadoop之editlogs和fsimage

一、概述

hadoop的namenode和secondarynamenode：

   1.   namenode负责

        负责客户端请求的响应

        元数据的管理（查询，修改）

    2.    元数据管理

        namenode对数据的管理采用了三种存储形式：

        内存元数据(NameSystem)

        磁盘元数据镜像文件

        数据操作日志文件（可通过日志运算出元数据）

    3.    元数据存储机制

            A、内存中有一份完整的元数据(内存meta data)

            B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)

            C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）注：当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存meta.data中

   4.   元数据的checkpoint

        每隔一段时间，会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）

      checkpoint过程：

        1.如果客户端涉及到元数据的更新（读数据不算更新，比如更改文件的名称、路径等、删除文件，增删改操作）。注意客户端不能更改文件内容，顶多可以追加操作。会有操作日志到NameNode的记录日志中。

        2.随着元数据的操作记录日志增多，secondary NameNode 也会定期的去请求NameNode是否需要checkpoint.

        3.如果得到应答，namenode会滚动当前的日志edits.inprogress,将当前记录的edits和namenode中的fsimage下载到secondary namenode中。

       4.secondary namenode会将其两者加载到内存合并，dump成新的image文件，重新上传到namenode中，重命名为新的fsimage.

       5.checkpoint时，会把正在写的edits滚动一下，然后将fsimage和日志下载到secondary namenode机器，只有第一次hdfs初始化时才下载fsimage,这时的文件操作没有那么大的数据量。以后只负责下载日志文件，合并旧的fsimage

注意：NameNode工作的时候元数据的查询都是找内存，只有NameNode宕机，内存中没有元数据，那hdfs重新启动的时候。数据就从fsimage和edits这两个文件中加载。

 namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据。

二、配置

修改两个文件：

 hdfs-site.xml

   
    <property>
      <name>dfs.namenode.secondary.http-address</name>
      <value>10.10.89.219:50070</value>
    </property>
   <property>
      <name>dfs.namenode.checkpoint.dir</name>
      <value>file:/data/hadoop-2.7.3/checkpoint</value>
    </property>
    <property>

core-site.xml

<property>
  <name>fs.checkpoint.period</name>
  <value>1800</value>
  <description>The number of seconds between two periodic checkpoints.
  </description>
</property>
<property>
  <name>fs.checkpoint.size</name>
  <value>67108864</value>
</property>

所有节点都要修改，当然可以指定secondarynamenode的启动节点为其他节点。