Hadoop1.0中fsimage和edits的合并

        在NameNode运行期间，HDFS的所有更新操作都是直接写到edits中的，所以edits这个文件会渐渐变大，这虽然对NameNode运行期间没影响，但是我们知道，当NameNode启动的时候，它会将fsimage和edits中的所有内容加载到内存中，然后再一条一条地执行edits中的记录，所以，如果edits这个文件很大，就会导致NameNode的启动非常缓慢，这显然不是用户想要看到的。

        SecondaryNameNode是HDFS架构中的一个组成部分，一般是将SecondaryNameNode单独运行在一台机器上，它的工作情况如下：

        （1）、SecondaryNameNode会定期和NameNode通信，请求其停止使用edits文件，暂时将新的写操作写到一个新的文件edits.new中，这个操作是瞬间完成的，上层写日志的函数完全感觉不到差别。

        （2）、SecondaryNameNode通过HTTP GET的方式从NameNode上获取fsimage和edits文件，并下载到本地相应目录下。

        （3）、SecondaryNameNode将下载下来的fsimage和edits加载到内存，然后一条一条地执行edits中的各项更新操作，使得内存中的fsimage保持最新，这个过程就是fsimage和edits的合并。

        （4）、SecondaryNameNode执行完（3）操作后，会通过POST的方式将新的fsimage文件发送到NameNode节点上

        （5）、NameNode从SecondaryNameNode接收到新的fsimage替换旧的fsimage，同时用edits.new替换掉edits，通过这个过程edits这个文件就变小了。

       

        SecondaryNameNode拥有的fsimage并不是最新的，因为它从NameNode下载fsimage和edits的时候，新的更新操作已经写到edits.new中去了。当然，如果NameNode中的fsimage出了问题，还是可以用SecondaryNameNode中的fsimage替换一下的，虽然不是最新的，但是我们可以将损失减少到最小。

        Hadoop2.0中fsimage和edits的合并实现和Hadoop1.0完全不一样，详情参见我的下一篇博文：Hadoop2.0中fsimage和edits的合并。