如何成功完成 namenode 重启并处理 5TB 的编辑文件

Question

我有一个名称节点必须在紧急情况下关闭，它已经 9 个月没有拍摄 FSImage，并且有大约 5TB 的编辑文件需要在下次重启时处理。自从大约 9 个月前以来，辅助名称节点还没有 运行（或执行过任何检查点操作），因此 9 个月大的 FSImage。

HDFS集群中大约有780万个inode。机器总内存约260GB。

我们尝试了 Java 堆大小、GC 算法等的几种不同组合...但未能找到允许重启完成而不会最终减慢速度的组合由于 FGC 导致爬网。

我有两个问题： 1. 有没有人找到一个 namenode 配置可以让这么大的编辑文件积压成功完成？

2. 我考虑过的另一种方法是在仅存在编辑文件的可管理子集的情况下重新启动名称节点。一旦名称节点出现并创建了一个新的 FSImage，将其关闭，复制下一个编辑文件子集，然后重新启动它。重复直到处理完整组编辑文件。这种方法行得通吗？就系统和文件系统的整体稳定性而言，这样做是否安全？

Answer 1

如果你的 hadoop 启用了 HA，那么 StandBy NN 应该会处理这个问题，如果你的辅助 NN 没有启用 HA。

检查这些名称节点进程的日志，了解为什么它无法 merge/fail。

这些下面的参数驱动你的编辑文件保存，它不应该创建这么多文件。

dfs.namenode.checkpoint.period
dfs.namenode.checkpoint.txns

手动执行合并的其他方式，但这将是临时。

hdfs dfsadmin -safemode enter
hdfs dfsadmin -rollEdits
hdfs dfsadmin -saveNamespace
hdfs dfsadmin -safemode leave

运行 以上命令应合并并保存命名空间。

Answer 2

我们能够使用我在问题 (2) 中针对原始 post 提出的建议解决 5TB 积压的编辑文件。这是我们经历的过程：

解决方案：

1. 确保名称节点来自数据节点"isolated"。这可以通过关闭数据节点，或者在名称节点离线时将它们从从属列表中删除来完成。这样做是为了防止名称节点在处理整个积压的编辑文件之前能够与数据节点通信。
2. 将整组编辑文件移动到名称节点 hdfs-site.xml 文件的 dfs.namenode.name.dir 属性 中配置的位置之外。
3. 将要处理的 下一个 编辑文件子集移动（或复制，如果您想维护备份）到 dfs.namenode.name.dir 位置。如果您不熟悉 FSImage 和编辑文件的命名约定，请查看下面的示例。它有望阐明下一个编辑文件子集的含义。
4. 更新文件 seen_txid 以包含由您在步骤 (3) 中复制的子集中的最后编辑文件表示的最后交易的值。因此，如果最后编辑的文件是 edits_0000000000000000011-0000000000000000020，您可能希望将 seen_txid 的值更新为 20。这实质上是在愚弄名称节点，使其认为该子集是 整个 组编辑文件。
5. 启动名称节点。如果您查看 HDFS Web UI 的 Startup Progress 选项卡，您将看到名称节点将从最新的现有 FSImage 开始，处理现有的编辑文件，创建一个新的 FSImage 文件，然后在等待数据节点联机时进入安全模式。
6. 关闭名称节点
7. 名称节点将创建 edits_inprogress_######## 个文件作为占位符。除非这是要处理的 final 组编辑文件，否则请删除此文件。
8. 重复步骤 3-7，直到您处理完所有积压的编辑文件。
9. 调出数据节点。一旦名称节点能够确认多个数据块的位置，它就应该退出安全模式。
10. 为您的集群设置辅助名称节点或高可用性，以便从现在开始定期创建 FSImage。

示例：

假设我们有 FSImage fsimage_0000000000000000010 和一堆编辑文件：edits_0000000000000000011-0000000000000000020 edits_0000000000000000021-0000000000000000030 edits_0000000000000000031-0000000000000000040 edits_0000000000000000041-0000000000000000050 edits_0000000000000000051-0000000000000000060 ... edits_0000000000000000091-0000000000000000100

按照上述步骤操作：

1. 所有数据节点都已脱机。
2. 所有编辑文件从 dfs.namenode.name.dir 复制到另一个位置，例如：/tmp/backup
3. 让我们一次处理 2 个文件。所以将 edits_0000000000000000011-0000000000000000020 和 edits_0000000000000000021-0000000000000000030 复制到 dfs.namenode.name.dir 位置。
4. 更新 seen_txid 以包含值 30，因为这是我们将在此 运行 期间处理的最后一笔交易。
5. 启动namenode，通过HDFS Web UI的Startup Progress选项卡确认它正确使用fsimage_0000000000000000010作为起点，然后处理edits_0000000000000000011-0000000000000000020和 edits_0000000000000000021-0000000000000000030。然后它创建了一个新的 FSImage 文件 fsimage_0000000000000000030` 并进入安全模式，等待数据节点出现。
6. 关闭名称节点
7. 删除占位符文件 edits_inprogress_######## 因为这不是要处理的最后一组编辑文件。
8. 继续下一个 运行 并重复直到处理完所有编辑文件。