Hadoop之SecondaryNameNode、CheckpointNode、BackupNode

曾经终败给现在 2022-05-21 09:23 169阅读 0赞

在Hadoop-2.x版本之前只存在**SecondaryNameNode**，没有**CheckpointNode**、**BackupNode**的概念，在2.x版本中引入了后两者，增强了对NameNode的同步和备份。现在就学习一下2.x版本中的SecondaryNameNode、CheckpointNode、BackupNode，在开始之前先了解一下NameNode中的两个重要文件fsimage和edits以及NameNode是如何使用这两个文件持久化命名空间的，比如HDFS文件系统的元数据。

NameNode使用fsimage和edits持久化命名空间，其中**fsimage**保存最新的检查点信息，**edits**保存自最新检查点后的命名空间的变化。当**NameNode**启动时，**NameNode**从**fsimage**中读取HDFS的状态，并会合并**edits**中信息到**fsimage**中以提供最新的文件系统元数据，这样**fsimage**中保存了HDFS的最新状态并会创建新的空的**edits**文件。由于**fsimage**和**edits**的合并只在**NameNode**启动时执行，如果**NameNode**长时间没有重新启动过，**edits**日志文件将会变得非常大，另一个**edits**日志文件太大的副作用是下次**NameNode**的重启将会花费更多的时间，因为需要更多的时间合并**fsimage**和**edits**文件。

由上面的描述可知**fsimage**和**edits**文件对整个HDFS有着至关重要的作用，一旦**NameNode**失效，比如宕机无法启动或者硬盘损坏，就将导致由于失去**fsimage**和**edits**文件而无法启动HDFS的现象，所以就出现了**SecondaryNameNode**、**CheckpointNode**、**BackupNode**用于对**fsimage**和**edits**文件备份，**SecondaryNameNode**是最先存在的，后两者是在2.x版本引入的。

**SecondaryNameNode**定期性地合并**fsimage**和**edits**文件，并保证**edits**日志文件大小不超过某个阈值。

**SecondaryNameNode**与**NameNode**运行在不同的主机上，并且内存要与**NameNode**的内存一样大小。

**SecondaryNameNode**将包含最新检查点信息的**fsimage**存储在与**NameNode**目录结构一致的目录中，这样**SecondaryNameNode**的**fsimage**总是在必要时可以被**NameNode**读取。**SecondaryNameNode**上检查点进程的启动被下面两个参数控制：

*  dfs.namenode.checkpoint.period，指定了两次连续的检查点之间的最大间隔，默认值为3600秒，即1小时
 *  dfs.namenode.checkpoint.txns，定义了NameNode上未检查的事务的数量，当NameNode上未检查的事务的数量达到该值时，将会启动紧急检查点而不管 dfs.namenode.checkpoint.period 设置的时间间隔是否有效，默认值为1000000。

**CheckpointNode**定期地创建命名空间的检查点。具体是如何做的呢？首先从**NameNode**下载**fsimage**和**edits**，然后在本地合并它们，然后将合并后的新的**fsimage**上传回**NameNode**，这样就避免了重新启动**NameNode**再合并**fsimage**和**edits**的问题。**CheckpointNode**与**NameNode**通常运行在不同的机器上，内存与**NameNode**的内存一样大小。使用参数dfs.namenode.backup.address设置**CheckpointNode**的地址，参数dfs.namenode.backup.http-address设置**CheckpointNode**的web地址，使用命令bin/hdfs namenode –checkpoint启动**CheckpointNode**。**CheckpointNode**控制检查点进程的参数与**SecondaryNameNode**上的参数一致，也是dfs.namenode.checkpoint.period和dfs.namenode.checkpoint.txns。**CheckpointNode**上保存**fsimage**和**edits**文件的目录结构与**NameNode**上的一致。

**BackupNode**不仅提供了与**CheckpointNode**相同的检查点功能，而且在内存中维护了文件系统命名空间的最新拷贝，该拷贝与**NameNode**中的状态总是同步的。除了从NameNode接收edits文件流外，BackupNode将这些edits文件在内存中创建副本，这样就创建了命名空间的备份。BackupNode不需要从NameNode下载fsimage和edits文件以创建检查点（CheckpointNode和SecondaryNameNode需要从NameNode下载这些文件），因为BackupNode已经在内存中最新的命名空间状态。BackupNode的检查点更加高效，因为它只需要将命名空间保存到本地fsimage文件中并重置edits文件。BackupNode的内存大小与NameNode的一样。

NameNode一次只支持一个BackupNode，并且在启用BackupNode的同时不启用CheckpointNode。这一点也可以从参数dfs.namenode.backup.addres和dfs.namenode.backup.http-addres推断而出，因为配置BackupNode和CheckpointNode都是这两个参数。使用命令bin/hdfs namenode –backup启动BackupNode。BackupNode为NameNode运行而不需要持久化存储提供了选项，可以将持久化命名空间状态的责任委托给BackupNode，因为BackupNode实时地从NameNode取得命名空间的状态。要想实现该目的，在启动NameNode时使用\-importCheckpoint选项，并在配置文件中将参数dfs.namenode.edits.dir设置为空。

上面的学习描述了Hadoop-2.x版本中SecondaryNameNode、CheckpointNode和BackupNode的工作机制，通过学习可以发现在Hadoop-2.x中，对NameNode中命名空间状态的备份更加强大和高效，整个集群也因此具有更高的可用性和数据完整性，对于更多的细节，比如轮询、传输文件流到BackupNode，则需要结合配置文件中的相关参数和源代码进行更深层次的学习。