Hadoop之SecondaryNameNode、CheckpointNode、BackupNode

        原文地址:https://blog.csdn.net/skywalker_only/article/details/39120455

        在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,则需要结合配置文件中的相关参数和源代码进行更深层次的学习。

猜你喜欢

转载自blog.csdn.net/pengjunlee/article/details/80913302