hadoop - 如何使用需要处理的 5TB 编辑文件成功完成名称节点重启

Question

我有一个 namenode 必须被关闭以应对紧急情况，该紧急情况已经 9 个月没有拍摄 FSImage，并且在下次重新启动时需要处理大约 5TB 的编辑文件。大约 9 个月前，辅助 namenode 没有运行(或执行任何检查点操作)，因此 FSImage 已有 9 个月的历史。

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

我们已经尝试了 Java 堆大小、GC 算法等的几种不同组合……但无法找到一种组合，可以在不因 FGC 而最终减速到爬行的情况下完成重启。

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

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

Answer 1

我们能够使用我在原始帖子的问题 (2) 中建议的版本来处理 5TB 的编辑文件积压。这是我们经历的过程:

解决方案:

确保名称节点与数据节点“隔离”。这可以通过关闭数据节点来完成，或者在名称节点离线时将它们从从属列表中删除。这样做是为了在处理整个积压的编辑文件之前阻止名称节点与数据节点通信。

将整个编辑文件集移动到 dfs.namenode.name.dir 上配置的位置之外的位置。 namenode 的 hdfs-site.xml 的属性文件。

将要处理的下一个编辑文件子集移动(或复制，如果您想保留备份)到 dfs.namenode.name.dir地点。如果您不熟悉 FSImage 和编辑文件的命名约定，请查看下面的示例。它有望阐明下一个编辑文件子集的含义。

更新文件seen_txid包含您在步骤 (3) 中复制的子集中的最后一个编辑文件表示的最后一个事务的值。所以如果最后的编辑文件是 edits_0000000000000000011-0000000000000000020 ，您可能想要更新 seen_txid 的值至20 .这实质上欺骗了namenode，使其认为这个子集是整个编辑文件集。

启动名称节点。如果你看看 Startup Progress在 HDFS Web UI 的选项卡中，您将看到 namenode 将从最新的当前 FSImage 开始，处理当前的编辑文件，创建一个新的 FSImage 文件，然后在等待数据节点联机时进入安全模式。

关闭namenode

会有edits_inprogress_########由namenode创建为占位符的文件。除非这是 最终 要处理的编辑文件集，请删除此文件。

重复步骤 3-7，直到您处理完所有积压的编辑文件。

调出数据节点。一旦能够确认多个数据 block 的位置，namenode 应该退出安全模式。

为您的集群设置一个辅助名称节点或高可用性，以便从现在开始定期创建 FSImage。

例子:

假设我们有 FSImage fsimage_0000000000000000010和一堆编辑文件: edits_0000000000000000011-0000000000000000020 edits_0000000000000000021-0000000000000000030 edits_0000000000000000031-0000000000000000040 edits_0000000000000000041-0000000000000000050 edits_0000000000000000051-0000000000000000060... edits_0000000000000000091-0000000000000000100
按照上述步骤:

所有数据节点都脱机。

从 dfs.namenode.name.dir 复制的所有编辑文件到另一个位置，例如:/tmp/backup

让我们一次处理 2 个文件。所以复制edits_0000000000000000011-0000000000000000020和 edits_0000000000000000021-0000000000000000030转到dfs.namenode.name.dir地点。

更新 seen_txid包含 30 的值因为这是我们将在此运行期间处理的最后一笔交易。

启动namenode，并通过HDFS Web UI的Startup Progress确认正确使用的标签 fsimage_0000000000000000010为起点，然后处理edits_0000000000000000011-0000000000000000020和 edits_0000000000000000021-0000000000000000030 .然后它创建了一个新的 FSImage 文件 fsimage_0000000000000000030` 并进入安全模式，等待数据节点出现。

关闭namenode

删除占位符文件edits_inprogress_########因为这不是要处理的最后一组编辑文件。

继续下一次运行并重复，直到处理完所有编辑文件。