【转】Hadoop 1.x中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的用户应该都知道在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就变小了！整个过程的执行能够经过下面的图说明：
　　在（1）步骤中，咱们谈到SecondaryNamenode会按期的和NameNode通讯，这个是须要配置的,能够经过core-site.xml进行配置，下面是默认的配置：

1 <property>
2   <name>fs.checkpoint.period</name>
3   <value>3600</value>
4   <description>The number of seconds between two periodic checkpoints.
5   </description>
6 </property>

 

　　其实若是当fs.checkpoint.period配置的时间尚未到期，咱们也能够经过判断当前的edits大小来触发一次合并的操做，能够经过下面配置

1 <property>
2   <name>fs.checkpoint.size</name>
3   <value>67108864</value>
4   <description>The size of the current edit log (in bytes) that triggers
5        a periodic checkpoint even if the fs.checkpoint.period hasn't expired.
6   </description>
7 </property>

 

　　当edits文件大小超过以上配置，即便fs.checkpoint.period还没到，也会进行一次合并。顺便说说SecondaryNamenode下载下来的fsimage和edits暂时存放的路径能够经过下面的属性进行配置：

 1 <property>
 2   <name>fs.checkpoint.dir</name>
 3   <value>${hadoop.tmp.dir}/dfs/namesecondary</value>
 4   <description>Determines where on the local filesystem the DFS secondary
 5       name node should store the temporary images to merge.
 6       If this is a comma-delimited list of directories then the image is
 7       replicated in all of the directories for redundancy.
 8   </description>
 9 </property>
10 
11 <property>
12   <name>fs.checkpoint.edits.dir</name>
13   <value>${fs.checkpoint.dir}</value>
14   <description>Determines where on the local filesystem the DFS secondary
15       name node should store the temporary edits to merge.
16       If this is a comma-delimited list of directoires then teh edits is
17       replicated in all of the directoires for redundancy.
18       Default value is same as fs.checkpoint.dir
19   </description>
20 </property>

 

　　从上面的描述咱们能够看出，SecondaryNamenode根本就不是Namenode的一个热备，其只是将fsimage和edits合并。其拥有的fsimage不是最新的，由于在他从NameNode下载fsimage和edits文件时候，新的更新操做已经写到edit.new文件中去了。而这些更新在SecondaryNamenode是没有同步到的！固然，若是NameNode中的fsimage真的出问题了，仍是能够用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage，虽然已经不是最新的fsimage，可是咱们能够将损失减少到最少！
　　在Hadoop 2.x经过配置JournalNode来实现Hadoop的高可用性，这样主被NameNode上的fsimage和edits都是最新的，任什么时候候只要有一台NameNode挂了，也可使得集群中的fsimage是最新状态！

 

转载自： http://www.iteblog.com/archives/969