Namenode和Secondary namenode怎么配合
1、Namenode的目录结构：
${dfs.name.dir}/current /VERSION
/edits
/fsimage
/fstime
dfs.name.dir是hdfs-site.xml里配置的若干个目录组成的列表：
<property> <name>dfs.name.dir</name> <value>/data/mm/hdfs/data1_name,/data/mm/hdfs/data2_name</value> <final>true</final> </property>
每个目录会有一份同样的拷贝，为了容灾考虑：往往会在将其中一个挂在NFS上。
2、Namenode的fsimage文件和edit log
客户端执行一个写或者删除操作时，会现在edit log中记录日志，Namenode在内存中维护着一份HDFS的元数据，当edit log中有产生变化时，内存中的元数据也会跟着刷新。向客户端返回成功之前，edit log都会先计入日志，并且要保证dfs.name.dir中定义的每个目录都记下了日志。
fsimage是元数据发送检查点时写入文件，由于fsimage文件往往很大，读写较慢。因此并不是每次HDFS的写入或者删除操作都会立即写fsimage文件。如果Namenode节点故障，namenode下次启动的时候，会把fsimage加载到内存中，应用edit log,edit log往往很大，导致操作往往很耗时。而在namenode整个启动的过程中，hdfs都是出于offline的不可用状态。
3、解决上面的问题，往往是在另外的一台机器上运行一个Secondary namenode。他的存在是为了不断的将namenode中的edit log应用到fsimage中，减少下次namenode的启动时间。整个过程如下：
(1)、namenode响应Secondary namenode请求，将edit log推送给Secondary namenode，开始重新写一个新的edit log。
(2)、Secondary namenode收到来自namenode的fsimage文件和edit log。
(3)、Secondary namenode将fsimage加载到内存，应用edit log，并生成一个新的fsimage文件。
(4)、Secondary namenode将新的fsimage推送给Namenode。
(5)、Namenode用新的fsimage取代旧的fsimage，在fstime文件中记下检查点发生的时间。
这样能够保证namenode有一个较新的fsimage文件和一个小的edit log 日志文件。上述过程也可以通过hadoop dfsadmin -saveNamespace命令完成。
这也解释了下面的问题：
(1)、为什么namenode和Secondary namenode需要同样大内存
(2)、大集群中namenode和Secondary namenode需要是各自独立的两个节点。
而触发Secondary namenode发生check point，受2个参数控制：
fs.checkpoint.period：默认一小时
fs.checkpoint.size：edit log 大小达到64MB