Hadoop 2.x 中的辅助 NameNode 使用和高可用性

Question

你能帮我解决以下情况吗？

1）在使用Hadoop V2时，我们是否在生产环境中使用Secondary NameNode？

2) 对于 Hadoop V2，假设我们在主动/被动连接中使用多个 NameNode 以实现高可用性，并且当编辑日志文件变得越来越大时，

编辑日志如何应用于 fsimage？如果是这样，那么在 Namenode 启动期间将巨大的 Edits 日志应用到 Namenode 会很耗时吗？（我们在 hadoop v1 中有 Secondary NameNode 来解决这个问题）

Answer 1

回答您的疑问：

1）在使用Hadoop V2时，我们是否在生产环境中使用Secondary NameNode？

如果您部署 StandByName 节点以实现 Name 节点的高可用性，则在生产环境中不需要辅助名称节点。

2) 在没有辅助节点的情况下，编辑日志如何应用于 fsimage？

要回答这个问题，您必须了解如何以两种不同的方式在 Hadoop 中实现高可用性。：高可用性与QJM和高可用性与NFS联合会

但是在这两种方法中，QJM（Quorum Journal Manager）是首选。

在典型的 HA 集群中，两台独立的机器被配置为 NameNode。在任何时间点，只有一个 NameNode 处于 Active 状态，另一个处于 Standby 状态。Active NameNode 负责集群中的所有客户端操作，而 Standby 只是充当从属节点，维护足够的状态以在必要时提供快速故障转移。

为了使备用节点保持其状态与活动节点同步，两个节点都与一组称为“JournalNodes”（JN）的独立守护程序进行通信。

当主动节点执行任何命名空间修改时，它会将修改记录持久地记录到这些 JN 中的大多数。Standby 节点从 JN 读取这些编辑并应用到它自己的命名空间。

在发生故障转移的情况下，备用节点将确保它在将自己提升到活动状态之前已读取来自 JounalNode 的所有编辑。这可确保在发生故障转移之前完全同步命名空间状态。

对于 HA 集群来说，一次只有一个 NameNode 处于活动状态至关重要。ZooKeeper 已被用于避免脑裂情况，以便名称节点状态不会因故障转移而发生分歧。

我在我的另一个 StackOverFlow 问题中详细解释了 Name 节点的故障转移过程：Hadoop Namenode 故障转移过程如何工作？