Hadoop之SecondaryNameNode、CheckpointNode、BackupNode

本文介绍Hadoop 2.x版本中SecondaryNameNode、CheckpointNode及BackupNode的工作机制,这些组件增强了NameNode的同步与备份能力,确保了HDFS的高可用性和数据完整性。
部署运行你感兴趣的模型镜像

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

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

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

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

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

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

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

       CheckpointNode定期地创建命名空间的检查点。具体是如何做的呢?首先从NameNode下载fsimageedits,然后在本地合并它们,然后将合并后的新的fsimage上传回NameNode,这样就避免了重新启动NameNode再合并fsimageedits的问题。CheckpointNodeNameNode通常运行在不同的机器上,内存与NameNode的内存一样大小。使用参数dfs.namenode.backup.address设置CheckpointNode的地址,参数dfs.namenode.backup.http-address设置CheckpointNode的web地址,使用命令bin/hdfs namenode –checkpoint启动CheckpointNodeCheckpointNode控制检查点进程的参数与SecondaryNameNode上的参数一致,也是dfs.namenode.checkpoint.perioddfs.namenode.checkpoint.txnsCheckpointNode上保存fsimageedits文件的目录结构与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.addresdfs.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,则需要结合配置文件中的相关参数和源代码进行更深层次的学习。

您可能感兴趣的与本文相关的镜像

Python3.8

Python3.8

Conda
Python

Python 是一种高级、解释型、通用的编程语言,以其简洁易读的语法而闻名,适用于广泛的应用,包括Web开发、数据分析、人工智能和自动化脚本

### Hadoop SecondaryNameNode 启动失败的原因分析 HadoopSecondaryNameNode 是用于辅助 NameNode 执行周期性的元数据检查点操作的重要组件。如果 SecondaryNameNode 未能成功启动,通常可能是由以下几个常见原因引起: 1. **临时目录冲突** 如果之前存在配置错误或者异常退出的情况,可能会导致 Hadoop 在 `tmp` 目录下创建了一些残留文件或锁文件,这些文件会干扰后续的正常运行[^1]。 2. **命名空间 ID 或集群 ID 不匹配** 这种情况通常是由于多次格式化 HDFS 集群(通过执行 `hdfs namenode -format` 命令),而未清理干净旧的数据节点名称节点之间的状态同步问题所引发的。具体表现为 NameNode DataNode 的 namespaceID 及 clusterID 不一致[^2]。 3. **权限设置不当** 若 Hadoop 配置中的用户角色定义不正确,则可能导致某些服务无法以指定身份运行。例如,默认情况下可能需要显式声明哪些用户可以分别作为 NameNode、DataNode SecondaryNameNode运行主体[^4]。 4. **其他潜在因素** 如网络连接不稳定、主机名解析失败等问题也可能间接影响到 SecondaryNameNode 的初始化过程[^3]。 --- ### 解决方案详解 针对上述提到的不同可能性,以下是对应的处理措施: #### 方法一:清除暂存路径 对于因遗留文件而导致的问题,可以通过手动移除 `/tmp/hadoop-*` 下的相关子目录来解决问题。此操作需谨慎进行,建议先停止整个 HDFS 服务再做修改: ```bash stop-dfs.sh rm -rf /tmp/hadoop-* start-dfs.sh ``` #### 方法二:统一 NamespaceID ClusterID 当怀疑是由于重复格式化造成一致性破坏时,应彻底清空所有存储位置上的历史数据后再重新构建环境。假设当前使用的 DFS 数据存放于本地磁盘分区 `/data/dfs/namenode` `/data/dfs/datanode` 中,则可按如下方式操作: ```bash # 删除原有内容 rm -r /data/dfs/* # 对新环境再次初始化 hdfs namenode -format ``` 注意每次重设前都要确认已经关闭所有的 Hadoop 守护进程以防误删正在工作的实例。 #### 方法三:调整用户映射关系 为了确保各个模块能够按照预期加载并工作,有必要核查甚至修正涉及的安全参数设定。编辑全局 profile 文件增加必要的条目即可实现这一目标: ```bash vi /etc/profile export HDFS_NAMENODE_USER=root export HDFS_DATANODE_USER=root export HDFS_SECONDARYNAMENODE_USER=root source /etc/profile ``` 完成更改后记得刷新 shell session 来应用最新的变量值。 #### 方法四:排查外部依赖条件 最后还应该核实是否存在诸如 DNS 查询失败之类的外围障碍阻止了正常的通信流程。比如尝试 ping 测试机器间的可达性以及验证 hosts 表项是否准确无误等等。 --- ### 总结说明 以上介绍了几种常见的致使 Hadoop SecondaryNameNode 失效的情形及其应对策略。实际部署过程中遇到的具体状况或许更为复杂多样,因此务必结合日志输出仔细甄别根本诱因所在,并采取针对性行动加以修复。
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值