一、NameNode的目录结构如下：

${dfs.name.dir}/current/VERSION

                                         /edits

                                         /fsimage

                                         /fstime

二、Secondary NameNode的目录结构如下：

${fs.checkpoint.dir}/current/VERSION

                                                /edits

                                                /fsimage

                                                /fstime

                                /previous.checkpoint/VERSION

                                                                      /edits

                                                                      /fsimage

                                                                      /fstime

如上图，Secondary NameNode主要是做Namespace image和Edit log合并的。

那么这两种文件是做什么的？当客户端执行写操作，则NameNode会在edit log记录下来，（我感觉这个文件有些像Oracle的online redo logo file）并在内存中保存一份文件系统的元数据。

Namespace image（fsimage）文件是文件系统元数据的持久化检查点，不会在写操作后马上更新，因为fsimage写非常慢（这个有比较像datafile）。

由于Edit log不断增长，在NameNode重启时，会造成长时间NameNode处于安全模式，不可用状态，是非常不符合Hadoop的设计初衷。所以要周期性合并Edit log，但是这个工作由NameNode来完成，会占用大量资源，这样就出现了Secondary NameNode，它可以进行image检查点的处理工作。步骤如下：

（1）       Secondary NameNode请求NameNode进行edit log的滚动（即创建一个新的edit log），将新的编辑操作记录到新生成的edit log文件；

（2）       通过http get方式，读取NameNode上的fsimage和edits文件，到Secondary NameNode上；

（3）       读取fsimage到内存中，即加载fsimage到内存，然后执行edits中所有操作（类似OracleDG，应用redo log），并生成一个新的fsimage文件，即这个检查点被创建；

（4）       通过http post方式，将新的fsimage文件传送到NameNode；

（5）       NameNode使用新的fsimage替换原来的fsimage文件，让（1）创建的edits替代原来的edits文件；并且更新fsimage文件的检查点时间。

整个处理过程完成。

Secondary NameNode的处理，是将fsimage和edites文件周期的合并，不会造成nameNode重启时造成长时间不可访问的情况。

hfds-secondary.jpg