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:</value>
    </property>
   <property>
      <name>dfs.namenode.checkpoint.dir</name>
      <value>file:/data/hadoop-2.7./checkpoint</value>
    </property>
    <property>

  <property>
    <name>dfs.namenode.checkpoint.period</name>
    <value></value>
  </property>
 <property>
    <name>dfs.namenode.checkpoint.txns</name>
    <value></value>
  </property>

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