Hadoop2.0 HA的checkpoint过程

hdfs将文件系统的元数据信息存放在fsimage和一系列的edits文件中。在启动HDFS集群时，系统会先加载fsimage，然后逐个执行所有Edits文件中的每一条操作，来获取完整的文件系统元数据。

Edits & fsimage文件

HDFS的存储元数据是由fsimage和edits文件组成。fsimage存放上次checkpoint生成的文件系统元数据，Edits存放文件系统操作日志。checkpoint的过程，就是合并fsimage和Edits文件，然后生成最新的fsimage的过程。

• Edits文件： 在配置了HA的hadoop2.x版本中，active namenode会及时把HDFS的修改信息（创建，修改，删除等）写入到本地目录，和journalnode上的Edits文件，每一个操作以一条数据的形式存放。Edits文件默认每2分钟产生一个。正在写入的Edits文件以edits_inprogress_*格式存在。

• fsimage文件： fsimage里保存的是HDFS文件系统的元数据信息。每次checkpoint的时候生成一个新的fsimage文件，fsimage文件同步保存在active namenode上和standby namenode上。是在standby namenode上生成并上传到active namenode上的。

checkpoint过程

配置了HA的HDFS中，有active和standby namenode两个namenode节点。他们的内存中保存了一样的集群元数据信息，这个后续我会详细用一篇文章介绍HA，所以这里就不多说了。因为standby namenode已经将集群状态存储在内存中了，所以创建检查点checkpoint的过程只需要从内存中生成新的fsimage。

详细过程如下： （standby namenode=SbNN， activenamenode=ANN）

1. SBNN查看是否满足创建检查点的条件：

（1） 距离上次checkpoint的时间间隔 >= ${dfs.namenode.checkpoint.period}
（2） Edits中的事务条数达到${dfs.namenode.checkpoint.txns}限制

这两个条件任何一个被满足了，就触发一次检查点创建。

2. SbNN将内存中当前的状态保存成一个新的文件，命名为fsimage.ckpt_txid。其中txid是最后一个edit中的最后一条事务的ID（transaction ID）。然后为该fsimage文件创建一个MD5文件，并将fsimage文件重命名为fsimage_txid。

3. SbNN向active namenode发送一条HTTP GET请求。请求中包含了SbNN的域名，端口以及新fsimage的txid。

4. ANN收到请求后，用获取到的信息反过来向SbNN再发送一条HTTP GET请求，获取新的fsimage文件。这个新的fsimage文件传输到ANN上后，也是先命名为fsimage.ckpt_txid，并为它创建一个MD5文件。然后再改名为fsimage_txid。fsimage过程完成。

checkpoint相关配置

dfs.namenode.checkpoint.period

--两次检查点创建之间的固定时间间隔，默认3600，即1小时。

dfs.namenode.checkpoint.txns

--未检查的事务数量。若没检查事务数达到这个值，也触发一次checkpoint，1,000,000。

dfs.namenode.checkpoint.check.period

--standby namenode检查是否满足建立checkpoint的条件的检查周期。默认60，即每1min检查一次。

dfs.namenode.num.checkpoints.retained

--在namenode上保存的fsimage的数目，超出的会被删除。默认保存2个。

dfs.namenode.num.checkpoints.retained

--最多能保存的edits文件个数，默认为1,000,000. 官方解释是为防止standby namenode宕机导致edits文件堆积的情况，设置的限制，不是太明白。

dfs.ha.tail-edits.period

--standby namenode每隔多长时间去检测新的Edits文件。只检测完成了的Edits， 不检测inprogress的文件。

参考文档： http://blog.cloudera.com/blog/2014/03/a-guide-to-checkpointing-in-hadoop/