如何成功完成名称节点重启，并使用价值5TB的编辑文件进行处理

Question

我有一个namenode，必须将其关闭以备不时之需，并且在9个月内未拍摄FSImage，并且有大约5TB的编辑文件需要在下次重启时处理。从大约9个月前（即9个月大的FSImage）以来，辅助namenode一直未运行（或未执行任何检查点操作）。

HDFS集群中大约有780万个索引节点。该计算机的总内存约为260GB。

我们已经尝试了Java堆大小，GC算法等的几种不同组合，但是找不到能够使重启完成而又不会由于FGC而最终减慢爬网速度的组合。< / p>

我有2个问题： 1.是否有人找到一个namenode配置，该配置可以使大量编辑文件积压成功完成？

1. 我考虑过的另一种方法是仅使用可管理的一部分编辑文件来重新启动namenode。名称节点启动并创建新的FSImage之后，将其关闭，复制下一个编辑文件子集，然后重新启动它。重复进行直到处理完所有编辑文件集。这种方法行得通吗？就系统和文件系统的整体稳定性而言，这样做安全吗？

Answer 1

如果您的hadoop启用了HA，那么StandBy NN应该已经做好了准备，如果您的辅助NN没有HA，则应该予以解决。

检查这些名称节点进程的日志，以了解其为何无法合并/失败。

以下这些参数可驱动您的编辑文件保存，并且它不应该创建这么多文件。

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）中建议的版本来浏览5TB的编辑文件积压。这是我们经历的过程：

解决方案：

1. 确保名称节点与数据节点“隔离”。这可以通过关闭数据节点，或者在namenode脱机时将它们从从属列表中删除来完成。这样做是为了防止namenode在处理整个待办事项编辑文件之前无法与datanode通信。
2. 将整个编辑文件集移动到名称节点dfs.namenode.name.dir文件的hdfs-site.xml属性的配置位置之外的位置。
3. 将要编辑的文件的 next 子集移动（或复制，如果您希望保留备份）到dfs.namenode.name.dir位置。如果您不熟悉FSImage的命名约定并编辑文件，请看以下示例。希望它将阐明 next 编辑文件子集的含义。
4. 更新文件seen_txid以包含由您在步骤（3）中复制的子集中的最后编辑文件表示的最后事务的值。因此，如果最后一个编辑文件是edits_0000000000000000011-0000000000000000020，则需要将seen_txid的值更新为20。这从根本上愚弄了名称节点，以为这个子集是整个编辑文件集。
5. 启动名称节点。如果您查看HDFS Web UI的Startup Progress标签，您会看到namenode将以最新的FSImage开始，处理当前的编辑文件，创建一个新的FSImage文件，然后进入等待数据节点联机时的安全模式。
6. 分解名称节点
7. namenode将创建edits_inprogress_########文件作为占位符。除非这是要处理的最终组编辑文件，否则请删除该文件。
8. 重复步骤3-7，直到完成整个待办事项编辑文件。
9. 启动数据节点。一旦能够确认多个数据块的位置，namenode应该退出安全模式。
10. 设置辅助名称节点或群集的高可用性，以便从现在开始定期创建FSImage。

示例：

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

遵循上述步骤：

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