HDFS SecondaryNameNode的原理和作用

Posted 2021-05-22 九万里大数据

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。

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文件名。

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