fsimage和edits合并实现

在NameNode运行期间，HDFS的全部更新操做都是直接写到edits中，长此以往edits文件将会变得很大；虽然这对NameNode运行时候是没有什么影响的，可是咱们知道当NameNode重启的时候，NameNode先将fsimage里面的全部内容映像到内存中，而后再一条一条地执行edits中的记录，当edits文件很是大的时候，会致使NameNode启动操做很是地慢，而在这段时间内HDFS系统处于安全模式，这显然不是用户要求的。能不能在NameNode运行的时候使得edits文件变小一些呢？实际上是能够的，本文主要是针对Hadoop 1.x版本，说明其是怎么将edits和fsimage文件合并的，Hadoop 2.x版本edits和fsimage文件合并是不一样的。

Hadoop 1.x

用过Hadoop的用户应该都知道在Hadoop里面有个SecondaryNamenode进程，从名字看来你们很容易将它看成NameNode的热备进程。其实真实的状况不是这样的。SecondaryNamenode是HDFS架构中的一个组成部分，它是用来保存namenode中对HDFS metadata的信息的备份，并减小namenode重启的时间而设定的！通常都是将SecondaryNamenode单独运行在一台机器上，那么SecondaryNamenode是如何namenode重启的时间的呢？来看看SecondaryNamenode的工做状况：
　　（1）、SecondaryNamenode会按期的和NameNode通讯，请求其中止使用edits文件，暂时将新的写操做写到一个新的文件edit.new上来，这个操做是瞬间完成，上层写日志的函数彻底感受不到差异；
　　（2）、SecondaryNamenode经过HTTP GET方式从NameNode上获取到fsimage和edits文件，并下载到本地的相应目录下；
　　（3）、SecondaryNamenode将下载下来的fsimage载入到内存，而后一条一条地执行edits文件中的各项更新操做，使得内存中的fsimage保存最新；这个过程就是edits和fsimage文件合并；
　　（4）、SecondaryNamenode执行完（3）操做以后，会经过post方式将新的fsimage文件发送到NameNode节点上
　　（5）、NameNode将从SecondaryNamenode接收到的新的fsimage替换旧的fsimage文件，同时将edit.new替换edits文件，经过这个过程edits就变小了！整个过程的执行能够经过下面的图说明：

从上面的描述咱们能够看出，SecondaryNamenode根本就不是Namenode的一个热备，其只是将fsimage和edits合并。其拥有的fsimage不是最新的，由于在他从NameNode下载fsimage和edits文件时候，新的更新操做已经写到edit.new文件中去了。而这些更新在SecondaryNamenode是没有同步到的！固然，若是NameNode中的fsimage真的出问题了，仍是能够用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage，虽然已经不是最新的fsimage，可是咱们能够将损失减少到最少！

Hadoop 2.x

咱们知道，在Hadoop 2.x中解决了NameNode的单点故障问题；同时SecondaryName已经不用了，而以前的Hadoop 1.x中是经过SecondaryName来合并fsimage和edits以此来减少edits文件的大小，从而减小NameNode重启的时间。而在Hadoop 2.x中已经不用SecondaryName，那它是怎么来实现fsimage和edits合并的呢？首先咱们得知道，在Hadoop 2.x中提供了HA机制（解决NameNode单点故障），能够经过配置奇数个JournalNode来实现HA，如何配置今天就不谈了！HA机制经过在同一个集群中运行两个NN（active NN & standby NN）来解决NameNode的单点故障，在任什么时候间，只有一台机器处于Active状态；另外一台机器是处于Standby状态。Active NN负责集群中全部客户端的操做；而Standby NN主要用于备用，它主要维持足够的状态，若是必要，能够提供快速的故障恢复。
　　为了让Standby NN的状态和Active NN保持同步，即元数据保持一致，它们都将会和JournalNodes守护进程通讯。当Active NN执行任何有关命名空间的修改，它须要持久化到一半以上的JournalNodes上(经过edits log持久化存储)，而Standby NN负责观察edits log的变化，它可以读取从JNs中读取edits信息，并更新其内部的命名空间。一旦Active NN出现故障，Standby NN将会保证从JNs中读出了所有的Edits，而后切换成Active状态。Standby NN读取所有的edits可确保发生故障转移以前，是和Active NN拥有彻底同步的命名空间状态

配置属性

在hdfs-site.xml里配置如下属性：

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600</value>
  <description>The number of seconds between two periodic checkpoints.
  </description>
</property>
 
<property>
  <name>dfs.namenode.checkpoint.check.period</name>
  <value>60</value>
  <description>The SecondaryNameNode and CheckpointNode will poll the NameNode
  every 'dfs.namenode.checkpoint.check.period' seconds to query the number
  of uncheckpointed transactions.
  </description>
</property>