SecondaryNameNode不就是NameNode的热备吗？

来源： https://www.jianshu.com/p/5b4dd843b29d

责编：小新

前言

HDFS SecondaryNameNode是干什么的？

这是道经典的基础面试题，笔者问过面试者不少次（固然也被面试官问过不少次）。从印象看，大约有一半的被面试者没法正确做答，给出的答案甚至有“不就是NameNode的热备嘛”。本文来简单聊聊相关的知识，为节省篇幅，将SecondaryNameNode简称SNN，NameNode简称NN。

NN与fsimage、edits文件

NN负责管理HDFS中全部的元数据，包括但不限于文件/目录结构、文件权限、块ID/大小/数量、副本策略等等。客户端执行读写操做前，先从NN得到元数据。当NN在运行时，元数据都是保存在内存中，以保证响应时间。

显然，元数据只保留在内存中是很是不可靠的，因此也须要持久化到磁盘。NN内部有两类文件用于持久化元数据：

• fsimage文件，以fsimage_为前缀，是序列化存储的元数据的总体快照；

• edits文件（又称edit log），以edits_为前缀，是顺序存储的元数据的增量修改（即客户端写入操做）日志。

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

可见，当前正在写入的edits文件名会有"inprogress"标识，而seen_txid文件保存的就是当前正在写入的edits文件的ID。

在任意时刻，最近的fsimage和edits文件的内容加起来就是全量元数据。NN在启动时，就会将最近的fsimage文件加载到内存，并重放它以后记录的edits文件，恢复元数据的现场。

SNN与checkpoint过程

为了不edits文件过大，以及缩短NN启动时恢复元数据的时间，咱们须要按期地将edits文件合并到fsimage文件，该合并过程叫作checkpoint（这个词是真正被用烂了哈）。

因为NN的负担已经比较重，再让它来进行I/O密集型的文件合并操做就不太科学了，因此Hadoop引入了SNN负责这件事。也就是说，SNN是辅助NN进行checkpoint操做的角色。

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

• dfs.namenode.checkpoint.period：触发checkpoint的周期长度，默认为1小时。

• dfs.namenode.checkpoint.txns：两次checkpoint之间最大容许进行的操做数，默认为100万。

只要知足上述两个参数的条件之一，就会触发checkpoint过程，叙述以下：

1. NN生成新的edits_inprogress文件，后续的修改日志将写入该文件中，以前正在写的edits文件即为待合并状态。

2. 将待合并的edits文件和fsimage文件一块儿复制到SNN本地。

3. SNN像NN启动时同样，将fsimage文件加载到内存，并重放edits文件进行合并。生成合并结果为fsimage.chkpoint文件。

4. SNN将fsimage.chkpoint复制回NN，并重命名为正式的fsimage文件名。

Hadoop官方给出的图示以下。虽然文件名称不一样，但思想是同样的。

若是开启了NN高可用呢？

上面说的都是集群只有一个NN的状况。若是有两个NN而且开启了HA的话，SNN就没用了——checkpoint过程会直接交给Standby NN来负责。Active NN会将edits文件同时写到本地与共享存储（QJM方案就是JournalNode集群）上去，Standby NN从JournalNode集群拉取edits文件进行合并，并保持fsimage文件与Active NN的同步。

---

- END -

有收获就点个「在看」吧 ▼

本文分享自微信公众号 - 老蒙大数据（simon_bigdata）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。