Namenode始终在内存中保存metedata（metedata里面保存的是元数据，比如整个文件系统的结构），用于处理“读请求”。但是我们把东西放在内存中，内存是易失的。
所以到有“写请求”到来时，namenode会首先写editlog到磁盘，成功返回后，才会修改内存，并且向客户端返回（注意我们的这个过程是同步的）
Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间通过合并editlog来更新内容。Secondary namenode就是用来更新fsimage的。
Secondary通知primary切换editlog
Secondary从primary获得fsimage和editlog（通过http，因为通常也不在同一个服务器上）
Secondary将fsimage载入内存，然后开始合并editlog
Secondary将新的fsimage发回给primary
Primary用新的fsimage替换旧的fsimage
fs.checkpoint.period 指定两次checkpoint的最大时间间隔，默认3600秒。
fs.checkpoint.size 规定edits文件的最大值，一旦超过这个值则强制checkpoint，不管是否到达最大时间间隔。默认大小是64M
因为namenode在启动的时候会合并fsimage和editlog（确保集群回到上一次的状态）,如果我们的日志文件太大就会需要特别长的时间，但是现在我们用secondarynamenode来定期的合并fsimage和editlog，这样的话就把日志文件限定在一个额度。下一次启动花的时间就少了。
这个是什么样的一个情况呢？我们的主节点namenode坏了，我们硬盘的数据恢复需要时间或者就恢复不了了，这个时候我们用如下办法来恢复：
1：我们找一台跟以前配置一模一样的服务器，最好就是当前的节点的服务器，然后修改一下配置，配置修改成namenode的
2：在新的服务器上新建一个文件夹，这个fs.name.dir指向这个文件夹.
3：secondarynamenode checkpoint文件存放在新建文件夹，该文件夹是fs.checkpoint.dr指向的文件夹
4：执行hadoop fs -importCheckpoint
5：这样fs.name.dir里面就有checkpoint文件了。但是fs.name.dir下有合法的fsimage的话会出错。
说说secondarynamenode的事儿,布布扣,bubuko.com
原文地址：http://my.oschina.net/u/1464779/blog/289895
