在 HDFS（Hadoop Distributed File System）中，Secondary NameNode (SNN) 的主要作用是辅助 NameNode 合并元数据文件，这个过程被称为 Checkpoint（检查点）。

为了让你更容易理解，我们需要先了解 NameNode 是如何存储元数据的，然后再看 Secondary NameNode 究竟帮了什么忙。

1. 为什么需要 Secondary NameNode？（背景）

NameNode 主要负责管理文件系统的元数据（文件目录树、文件到数据块的映射等）。为了保证性能，NameNode 把元数据保存在内存中。但为了防止断电数据丢失，它必须把数据持久化到硬盘上。HDFS 采用了两种文件来持久化元数据：

• fsimage（镜像文件）： 元数据在某一时刻的完整快照（相当于数据库的冷备份）。
• edits（编辑日志）： 记录了客户端对 HDFS 的所有增删改操作（相当于数据库的增量日志）。

痛点： 随着系统运行，edits 日志文件会越来越大。如果 NameNode 突然宕机重启，它需要先加载 fsimage，然后逐条重放庞大的 edits 日志来恢复内存状态。这会导致 NameNode 启动非常缓慢，且耗费大量磁盘空间。

2. Secondary NameNode 的核心作用

Secondary NameNode 就是为了解决上述痛点而诞生的，它的具体作用包括以下几点：

① 合并 fsimage 和 edits 文件（Checkpoint）

SNN 会定期从 NameNode 下载当前的 fsimage 和 edits 文件，在自己的内存中将这两者合并，生成一个新的、包含最新状态的 fsimage 文件，然后再推送回 NameNode。

② 防止 edits 日志文件过大

通过定期合并，NameNode 上的旧 edits 日志就可以被清空，从而有效控制了 edits 日志文件的体积，节省了磁盘空间。

③ 大大加速 NameNode 的启动过程

因为 SNN 已经提前把增量操作（edits）合并到了基准快照（fsimage）中，所以当 NameNode 重启时，只需要加载最新的 fsimage 和非常少量的新 edits 即可，极大缩短了启动时间。

④ 提供有限的元数据“冷备份”

SNN 本地会保存最新合并出的 fsimage 文件。如果 NameNode 的硬盘彻底损坏且无法恢复，管理员可以从 SNN 拷贝 fsimage 来恢复部分元数据（注意：会丢失自上次 Checkpoint 以来最新的操作数据）。

---

3. Checkpoint 的工作流程（简述）

1. 触发： SNN 定期（如每小时）或当 edits 文件达到一定大小时（如100万条事务），向 NameNode 发起 Checkpoint 请求。
2. 滚动日志： NameNode 停止向当前的 edits 文件写入，生成一个新的 edits.new 用于记录新的操作记录。
3. 下载： SNN 将旧的 edits 和 fsimage 通过 HTTP 下载到自己的本地。
4. 合并： SNN 在内存中加载 fsimage，并重放 edits 中的操作，生成一个新的镜像文件 fsimage.ckpt。
5. 上传： SNN 将 fsimage.ckpt 上传回 NameNode。
6. 替换： NameNode 将接收到的 fsimage.ckpt 重命名为 fsimage，并将 edits.new 改名为当前的 edits，完成一次循环。

---

⚠️ 一个极其重要的纠正（面试常考点）

Secondary NameNode 绝对不是 NameNode 的热备（Backup / Standby）！

• 如果 NameNode 宕机，Secondary NameNode 不能自动接管服务，HDFS 集群依然会瘫痪。它只是一个“干苦力”的合并节点。
• 现代 Hadoop（Hadoop 2.x 及以上版本）： 在生产环境中通常会配置 HA（高可用）模式。在 HA 模式下，会有 Active NameNode 和 Standby NameNode。此时，Standby NameNode 承担了合并元数据（Checkpoint）的工作，Secondary NameNode 就不再需要，也不应该被启动了。 只有在非 HA 的伪分布式或微型集群中，才会看到 SNN 的身影。