Namenode的工作特点

Namenode始终在内存中保存metedata（metedata里面保存的是元数据，比如整个文件系统的结构），用于处理“读请求”。但是我们把东西放在内存中，内存是易失的。

所以到有“写请求”到来时，namenode会首先写editlog到磁盘，成功返回后，才会修改内存，并且向客户端返回（注意我们的这个过程是同步的）

Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间通过合并editlog来更新内容。Secondary namenode就是用来更新fsimage的。

secondary namenode的工作流程

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

为什么secondarynamenode能减少namenode启动的时间呢？

因为namenode在启动的时候会合并fsimage和editlog（确保集群回到上一次的状态）,如果我们的日志文件太大就会需要特别长的时间，但是现在我们用secondarynamenode来定期的合并fsimage和editlog，这样的话就把日志文件限定在一个额度。下一次启动花的时间就少了。   

Namenode宕机了，怎么恢复数据?

这个是什么样的一个情况呢？我们的主节点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的话会出错。