HDFS - CheckPoint机制是怎么实现的

HDFS - 什么是元数据我们提到了CheckPoint机制,主要就是合并多个edits文件,NameNode的压力已经很大了,所以合并的事情,并不是NameNode来做的,而是SecondaryNamenode来支持的,如果在高可用集群或者联邦集群,那合并的事情,就是有standby节点的NameNode来做的。

SecondaryNamenode

HDFS - 什么是元数据中提到了磁盘中的元数据包括fsimage、edits_inprogress、edits、seen_txid、VERSION这些文件。
刚开始的时候,是没有edits文件的。
HDFS - CheckPoint机制是怎么实现的_第1张图片
当NameNode运行一段时间后,就开始慢慢的生成多个edits文件,文件名格式是edits_数字-数字(数字是19位的,我这里画图写了4位),并且是递增的。
HDFS - CheckPoint机制是怎么实现的_第2张图片
前面的文章说过,NameNode重启的时候,就会加载edits_inprogress、edits、以及fsimage这几个文件,因为这几个文件合起来就是完整的元数据。由于edits会越来越多,所以就需要进行合并,提高启动的速度,但是NameNode的压力已经很大了,所以需要SecondaryNamenode来做。
SecondaryNamenode会隔一段时间就去请求NameNode获取fsimage和edits文件,如果两次CheckPoint的时间已经超过1个小时或者两次CheckPoint的操作记录已经超过10w条,那NameNode就会生成一个空的edits.new文件,同时把edits文件以及fsimage文件发送给SecondaryNamenode。
HDFS - CheckPoint机制是怎么实现的_第3张图片
SecondaryNamenode就会在本地把edits文件和fsimage文件进行合并,生成一个新的fsimage.ckpt文件。
HDFS - CheckPoint机制是怎么实现的_第4张图片
生成后的fsimage.ckpt就会发给NameNode,NameNode就会把这个文件覆盖原来的fsimage,fsimage_0006此时后面的数字,对应着edits_0001到edits_0006的元数据集合。此时就会把旧的edits删除,并且把edits.new文件重命名edis文件。
有时候我们会看到fsimage会有两个,这个是为了最新fsimage不可用的时候,能回滚之前的元数据状态,当然新增的元数据就丢失了。
HDFS - CheckPoint机制是怎么实现的_第5张图片

集群

如果非集群的话,元数据的持久化是写入磁盘,如果是集群的话,元数据除了写入磁盘,还会写入JournalNode。所以刚开始的时候,active节点的NameNode和JournalNode的元数据是一样的。
HDFS - CheckPoint机制是怎么实现的_第6张图片
standby节点的NameNode,每隔60秒,就会去JournalNode读取元数据信息。
HDFS - CheckPoint机制是怎么实现的_第7张图片
当CheckPoint触发的时候,就会把edits文件和fsimage文件,合并生成新的fsimage文件。
HDFS - CheckPoint机制是怎么实现的_第8张图片
然后standby节点的NameNode就会把新的fsimage发送给active节点的NameNode。active节点的NameNode替换旧的fsimage,就会把edits文件删除。
HDFS - CheckPoint机制是怎么实现的_第9张图片
至此,完成了edits文件和fsimage的合并。

你可能感兴趣的:(hadoophdfs)