在《Hadoop文件系统元数据fsimage和编辑日志edits》文章中谈到了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进行配置，下面是默认的配置：
| 2 | <name>fs.checkpoint.period</name> |
| 4 | <description>The number of seconds between two periodic checkpoints. |
其实如果当fs.checkpoint.period配置的时间还没有到期，我们也可以通过判断当前的edits大小来触发一次合并的操作，可以通过下面配置
| 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. |
当edits文件大小超过以上配置，即使fs.checkpoint.period还没到，也会进行一次合并。顺便说说SecondaryNamenode下载下来的fsimage和edits暂时存放的路径可以通过下面的属性进行配置：
| 02 | <name>fs.checkpoint.dir</name> |
| 03 | <value>${hadoop.tmp.dir}/dfs/namesecondary</value> |
| 04 | <description>Determines where on the local filesystem the DFS secondary |
| 05 | name node should store the temporary images to merge. |
| 06 | If this is a comma-delimited list of directories then the image is |
| 07 | replicated in all of the directories for redundancy. |
| 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 |
从上面的描述我们可以看出，SecondaryNamenode根本就不是Namenode的一个热备，其只是将fsimage和edits合并。其拥有的fsimage不是最新的，因为在他从NameNode下载fsimage和edits文件时候，新的更新操作已经写到edit.new文件中去了。而这些更新在SecondaryNamenode是没有同步到的！当然，如果NameNode中的fsimage真的出问题了，还是可以用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage，虽然已经不是最新的fsimage，但是我们可以将损失减小到最少！
在Hadoop 2.x通过配置JournalNode来实现Hadoop的高可用性，可以参见
《Hadoop2.2.0中HDFS的高可用性实现原理》，这样主被NameNode上的fsimage和edits都是最新的，任何时候只要有一台NameNode挂了，也可以使得集群中的fsimage是最新状态！关于Hadoop 2.x是如何合并fsimage和edits的，可以阅读本博客的
《Hadoop 2.x中fsimage和edits合并实现》。
/2 
