FSImage 和 EditsLog-- 转载

HDFS 是一个分布式文件存储系统，文件分布式存储在多个 DataNode 节点上。一个文件存储在哪些 DataNode 节点的哪些位置的元数据信息（metadata）由 NameNode 节点来处理。而随着存储文件的增多，NameNode 上存储的信息也会越来越多。那么 HDFS 是如何及时更新这些metadata的呢？

完整的 metadata 信息就应该由 FSImage 文件和 edit log 文件组成。fsimage 中存储的信息就相当于整个 hdfs 在某一时刻的一个快照。

在某一次启动HDFS时，会从 FSImage 文件中读取当前 HDFS 文件的 metadata ，之后对 HDFS 的所有操作都会记录到 edit log 文件中。比如下面这个操作过程：

 

edit log 1.jpg

fsImage 文件和 editsLog 文件是通过 id 来互相关联的

 

# 在没有配置 HA 的情况下，fsimage 与 editslog 保存在 namenode 目录
dfs.namenode.name.dir

# 在配置了 HA with QJM 时
dfs.journalnode.edits.dir

<property>
    <name>dfs.journalnode.edits.dir</name>
    <value>/opt/modules/hadoop-2.6.0-cdh5.8.0/data/journal</value>
</property>

edit log 2.jpg

 

从上图可以看到：

 

1、edit log文件以 edits_ 开头，后面跟一个txid范围段，并且多个edit log之间首尾相连，
2、正在使用的 edit log 名字为 edits_inprogress_txid
3、会保存两个fsimage文件，文件格式为fsimage_txid

但是这里会出现一个问题，一旦重新启动 HDFS 时，由于需要加载 fsimage，以及所有的 txid 大于 fsimage 的 edit log，当 edit log 文件越来越多、越来越大时，整个重启过程就会耗时非常之久。

Checkpoint 机制

fsimage 和 edit log 合并的过程如下图所示：

 

Checkpoint 1.jpg

 

1、这个合并过程是一个很耗I/O与CPU的操作，并且在进行合并的过程中肯定也会有其他应用继续访问和修改hdfs文件
2、一般而言这个合并过程不是在单一的 NameNode 节点上进行。假如 HDFS 没有做 HA ，checkpoint 由 SecondNameNode 进程(一般SecondNameNode单独起在另一台机器上)来进行
3、在HA模式下，checkpoint 则由 StandBy 状态的 NameNode 来进行

那么什么时候进行 checkpoint ，由下面两个参数来确定：

1. dfs.namenode.checkpoint.preiod(默认值是3600，即1小时)，period参数表示，经过1小时就进行一次checkpoint
2. dfs.namenode.checkpoint.txns(默认值是1000000)来决定，txns参数表示，hdfs经过100万次操作后就要进行checkpoint了。
3. 这两个参数任意一个得到满足，都会触发checkpoint过程
4. 进行 checkpoint 的节点每隔 dfs.namenode.checkpoint.check.period(默认值是60）秒就会去统计一次hdfs的操作次数

HA模式下 Checkpoint 过程

在HA模式下 checkpoint 过程由StandBy NameNode来进行，Active NameNode将edit log文件会同时写入多个 JournalNodes 节点的 dfs.journalnode.edits.dir 路径下，（JournalNodes 的个数为大于1的奇数，当有不超过一半的 JournalNodes 出现故障时，仍然能保证集群的稳定运行）。
　　StandBy NameNode 会读取 FSImage 文件中的内容，并且每隔一段时间就会把 Active NameNode 写入edit log中的记录读取出来，这样 StandBy NameNode 的NameNode进程中一直保持着 hdfs 文件系统的最新状况的 namespace。当达到 checkpoint 条件的某一个时，就会直接将该信息写入一个新的 FSImage 文件中，然后通过HTTP传输给 Active NameNode 。

 

Checkpoint 2.jpg

JournalNode.png

如上图所示，整个同步过程如下：

1. StandBy NameNode 检查是否达到 checkpoint 条件：离上一次checkpoint操作是否已经有一个小时，或者HDFS已经进行了100万次操作。
2. StandBy NameNode 检查达到 checkpoint 条件后，将该 namespace 以fsimage.ckpt_txid 格式保存到 StandBy NameNode 的磁盘上，并且随之生成一个MD5文件。然后将该fsimage.ckpt_txid文件重命名为fsimage_txid。
3. 然后 StandBy NameNode 通过HTTP联系 Active NameNode。
4. Active NameNode 通过HTTP从 StandBy NameNode 获取最新的fsimage_txid文件并保存为fsimage.ckpt_txid，然后也生成一个MD5，将这个MD5与SBNN的MD5文件进行比较，确认ANN已经正确获取到了SBNN最新的fsimage文件。然后将fsimage.ckpt_txid文件重命名为fsimage_txit。
5. 通过上面一系列的操作，StandBy NameNode 上最新的 FSImage 文件就成功同步到了 Active NameNode 上。

JournalNode 其实不参与 NameNode 的 metadata 同步之类的操作，它只是个忠实的存储，存储来自于NameNode 的操作日志，Active NameNode 在文件系统被修改时，会向JournalNode写入修改记录，而 Standby NameNode 可以方便的读取到这样的修改记录。