vlambda博客
学习文章列表

HDFS SecondaryNameNode的原理和作用

NameNode与fsimage、edits文件

NameNode(简称NN)负责管理和保存HDFS中所有的元数据,包括但不限于文件/目录结构、文件权限、块ID/大小/数量、副本策略等等。当NameNode在运行时,元数据都是保存在内存中,以保证响应时间。元数据同时也会持久化到磁盘,dfs.namenode.name.dir参数指定了元数据的磁盘保存路径。NameNode内部有两类文件用于持久化元数据:

fsimage文件,以fsimage_为前缀,是序列化存储的元数据的整体快照;edits文件(又称edit log),以edits_为前缀,是顺序存储的元数据的增量修改事务日志。

这两类文件均存储在NameNode的${dfs.namenode.name.dir}/current/路径下,如下图所示。

可见,当前正在写入的edits文件名会有"inprogress"标识,而seen_txid文件保存的就是当前正在写入的edits文件的ID。在任意时刻,最近的fsimage和edits文件的内容加起来就是全量元数据。NameNode在启动时,就会将最近的fsimage文件加载到内存,并重放它之后记录的edits文件,恢复元数据的现场。

SecondaryNameNode与checkpoint过程

为了避免edits文件过大,以及缩短NameNode启动时恢复元数据的时间,我们需要定期地将edits文件合并到fsimage文件,该合并过程叫做checkpoint。对于大型的HDFS集群,fsimage能达到几个GB大小,NameNode通常需要处理非常多的事务,导致NameNode的负担比较重,再让它来进行I/O密集型的文件合并操作就不太合适了,所以HDFS引入了SecondaryNameNode专门负责这件事。也就是说,SecondaryNameNode(简称SNN)是辅助NameNode进行checkpoint操作的角色。

checkpoint的触发由hdfs-site.xml中的两个参数来控制:

dfs.namenode.checkpoint.period:触发checkpoint的周期长度,默认为1小时。dfs.namenode.checkpoint.txns:两次checkpoint之间最大允许进行的操作数,默认为100万。

两个参数只要满足其一,就会触发checkpoint过程。默认情况下,SNN每隔1小时进行一次checkpoint,但如果还没到1小时,距离上一次checkpoint后事务累积已经超过了1百万,就会立刻触发一次checkpoint。

HDFS SecondaryNameNode的原理和作用

checkpoint过程如下:

SNN请求NN生成新的edits_inprogress文件,后续新的edits将写入该文件中,之前正在写的edits文件成为待合并状态。NN同时更新seen_txid文件的内容为最新的edit文件ID。SNN使用HTTP GET请求的方式将待合并的edits文件和fsimage文件从NN复制到SNN本地。SNN将fsimage文件加载到内存,并重放edits文件中的事务进行合并,保存为新的fsimage文件。SNN使用HTTP PUT请求的方式将合并后的fsimage复制回NN,保存为.ckpt临时文件。NN将.ckpt临时文件重命名为正式的fsimage文件名。

HDFS SecondaryNameNode的原理和作用


SecondaryNameNode的目录结构如下,可以与前面NameNode的目录结构比对一下,加深认识。

如果开启了NameNode高可用

上面说的都是集群只有一个NameNode的情况。如果HDFS NameNode开启了HA的话,SecondaryNameNode会被替换成standby NameNode,checkpoint过程会直接交给standby NameNode来负责。active NameNode会将edits文件同时写到本地与共享存储(比如QJM方案就是JournalNode集群)上去,standby NameNode从JournalNode集群拉取edits文件,和从active NameNode拉取的fsimage进行合并,并保持fsimage文件与active NameNode的同步。


引用链接

[1] jwldata.com: https://www.jwldata.com