在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的合并。