目的

本指南概述了HDFS高可用性（HA）功能以及如何使用NFS为NameNodes所需的共享存储配置和管理HA HDFS群集。

本文档假定读者对HDFS集群中的一般组件和节点类型有一般性的了解。有关详细信息，请参阅HDFS体系结构指南。

注意：使用Quorum Journal Manager或常规共享存储

本指南讨论如何使用共享NFS目录配置和使用HDFS HA，以共享活动和备用NameNode之间的编辑日志。有关如何使用Quorum Journal Manager而不是NFS配置HDFS HA的信息，请参阅此备用指南。

背景

在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个群集都有一个NameNode，如果该机器或进程变得不可用，整个群集将无法使用，直到NameNode重新启动或在单独的计算机上启动。

这在两个主要方面影响了HDFS集群的总体可用性：

  • 对于计划外事件（例如计算机崩溃），在操作员重新启动NameNode之前，群集将不可用。

  • 计划维护事件（如NameNode计算机上的软件或硬件升级）将导致群集停机时间窗口。

HDFS高可用性功能通过提供在具有热备用的主动/被动配置中的同一群集中运行两个（或更多，Hadoop 3.0.0）冗余NameNode的选项来解决上述问题。这允许在机器崩溃的情况下快速故障转移到新的NameNode，或者为了计划维护而优雅地管理员启动的故障转移。

架构

在典型的HA群集中，两个或多个单独的计算机配置为NameNode。在任何时间点，其中一个NameNode处于Active 状态，而其他NameNode 处于Standby 状态。Active NameNode负责集群中的所有客户端操作，而Standby只是充当从属服务器，维持足够的状态以在必要时提供快速故障转移。

为了使备用节点保持其状态与活动节点同步，当前实现要求节点可以访问共享存储设备上的目录（例如，来自NAS的NFS安装）。在将来的版本中可能会放宽此限制。

当Active节点执行任何名称空间修改时，它会将修改记录持久地记录到存储在共享目录中的编辑日志文件中。备用节点不断观察此目录以进行编辑，并在查看编辑时将其应用于自己的命名空间。如果发生故障转移，备用数据库将确保在将自身升级为活动状态之前已从共享存储中读取所有编辑内容。这可确保在发生故障转移之前完全同步命名空间状态。

为了提供快速故障转移，备用节点还必须具有关于群集中块的位置的最新信息。为了实现这一点，DataNode配置了所有NameNode的位置，并将块位置信息和心跳发送到所有NameNode。

对于HA群集的正确操作而言，一次只有一个NameNode处于活动状态至关重要。否则，命名空间状态将在两者之间快速分歧，冒着数据丢失或其他不正确结果的风险。为了确保此属性并防止所谓的“裂脑情景”，管理员必须为共享存储配置至少一种防护方法。在故障转移期间，如果无法验证先前的活动节点是否已放弃其活动状态，则防护进程负责切断先前Active对共享编辑存储的访问。这可以防止它对命名空间进行任何进一步的编辑，从而允许新的Active安全地进行故障转移。

硬件资源

要部署HA群集，您应准备以下内容：

  • NameNode计算机 - 运行Active和Standby NameNode的计算机应具有彼此相同的硬件，以及与非HA集群中使用的硬件等效的硬件。

  • 共享存储 - 您需要拥有NameNode计算机具有读/写访问权限的共享目录。通常，这是一个支持NFS的远程文件管理器，并安装在每个NameNode计算机上。目前仅支持单个共享编辑目录。因此，系统的可用性受到此共享编辑目录的可用性的限制，因此为了移除所有单点故障，共享编辑目录需要冗余。具体而言，存储的多个网络路径以及存储本身（磁盘，网络和电源）的冗余。因此，建议共享存储服务器是高质量的专用NAS设备，而不是简单的Linux服务器。

请注意，在HA群集中，备用NameNode还会执行命名空间状态的检查点，因此无需在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。事实上，这样做会是一个错误。这还允许正在重新配置启用HA的HDFS群集的人员启用HA，以重用他们之前专用于Secondary NameNode的硬件。

部署

配置概述

与联邦配置类似，HA配置是向后兼容的，允许现有的单个NameNode配置无需更改即可运行。新配置的设计使得集群中的所有节点可以具有相同的配置，而无需根据节点的类型将不同的配置文件部署到不同的计算机。

与HDFS Federation一样，HA集群重用名称服务ID来标识单个HDFS实例，该实例实际上可能包含多个HA NameNode。此外，HA添加了一个名为NameNode ID的新抽象。群集中的每个不同的NameNode都有一个不同的NameNode ID来区分它。要支持所有NameNode的单个配置文件，相关配置参数后缀为nameservice ID和NameNode ID。

配置细节

要配置HA NameNode，必须向hdfs-site.xml配置文件添加多个配置选项。

您设置这些配置的顺序并不重要，但您为dfs.nameservices和 dfs.ha.namenodes.[nameservice ID]选择的值将确定后面的那些键。因此，在设置其余配置选项之前，您应该决定这些值。

  • dfs.nameservices - 此新名称服务的逻辑名称

    为此名称服务选择一个逻辑名称，例如“mycluster”，并使用此逻辑名称作为此config选项的值。您选择的名称是任意的。它既可用于配置，也可用作群集中绝对HDFS路径的权限组件。

    注意：如果您还在使用HDFS Federation，则此配置设置还应包括其他名称服务列表，HA或其他，以逗号分隔列表。

    <property>
  <name>dfs.nameservices</name>
  <value>mycluster</value>
</property>

  • dfs.ha.namenodes。[nameservice ID] - nameservice中每个NameNode的唯一标识符

    配置逗号分隔的NameNode ID列表。DataNodes将使用它来确定集群中的所有NameNode。例如，如果您之前使用“mycluster”作为名称服务ID，并且您希望使用“nn1”，“nn2”和“nn3”作为NameNodes的各个ID，则可以这样配置：

    <property>
  <name>dfs.ha.namenodes.mycluster</name>
  <value>nn1,nn2,nn3</value>
</property>

    注意： HA的NameNode最小数量为2，但您可以配置更多。由于通信开销，建议不要超过5 - 推荐3个NameNodes。

  • dfs.namenode.rpc-address。[nameservice ID]。[name node ID] - 要监听的每个NameNode的完全限定的RPC地址

    对于两个先前配置的NameNode ID，请设置NameNode进程的完整地址和IPC端口。请注意，这会产生两个单独的配置选项。例如：

    <property>
  <name>dfs.namenode.rpc-address.mycluster.nn1</name>
  <value>machine1.example.com:8020</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn2</name>
  <value>machine2.example.com:8020</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn3</name>
  <value>machine3.example.com:8020</value>
</property>

    注意：如果您愿意，可以类似地配置“ servicerpc-address ”设置。

  • dfs.namenode.http-address.[nameservice ID].[name node ID] - 要监听的每个NameNode的完全限定HTTP地址

    与上面的rpc-address类似，设置两个NameNodes的HTTP服务器的地址以进行侦听。例如：

    <property>
  <name>dfs.namenode.http-address.mycluster.nn1</name>
  <value>machine1.example.com:9870</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn2</name>
  <value>machine2.example.com:9870</value>
</property>
<property>
  <name>dfs.namenode.http-address.mycluster.nn3</name>
  <value>machine3.example.com:9870</value>
</property>

    注意：如果启用了Hadoop的安全功能，则还应为每个NameNode 设置https-address。

  • dfs.namenode.shared.edits.dir - 共享存储目录的位置

    这是一个配置远程共享编辑目录的路径的地方，备用NameNode用它来保持与Active NameNode所做的所有文件系统更改保持同步。您应该只配置其中一个目录。此目录应在NameNode计算机上以r/w方式挂载。此设置的值应该是NameNode计算机上此目录的绝对路径。例如：

    <property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>file:///mnt/filer1/dfs/ha-name-dir-shared</value>
</property>

  • dfs.client.failover.proxy.provider。[nameservice ID] - HDFS客户端用于联系Active NameNode的Java类

    配置Java类的名称，DFS客户端将使用该名称来确定哪个NameNode是当前的Active，以及哪个NameNode当前正在为客户端请求提供服务。目前Hadoop附带的两个实现是ConfiguredFailoverProxyProvider和RequestHedgingProxyProvider（对于第一次调用，它同时调用所有名称节点以确定活动的名称，并在后续请求中调用活动的名称节点直到发生故障转移），所以除非您使用自定义代理提供程序，否则请使用其中一个。

    <property>
  <name>dfs.client.failover.proxy.provider.mycluster</name>
  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

  • dfs.ha.fencing.methods - 脚本或Java类的列表，用于在故障转移期间屏蔽 Active NameNode

    对于系统的正确性而言，在任何给定时间只有一个NameNode处于活动状态是至关重要的。因此，在故障转移期间，我们首先确保Active NameNode处于Standby状态，或者进程已终止，然后再将另一个NameNode转换为Active状态。为此，您必须至少配置一个防护方法。它们被配置为回车分隔列表，将按顺序尝试，直到指示防护成功为止。Hadoop有两种方法：shell和sshfence。有关实现自定义防护方法的信息，请参阅org.apache.hadoop.ha.NodeFencer类。

    sshfence - SSH到Active NameNode并终止进程

    该sshfence选项SSHes到目标节点，并使用定影杀死进程监听服务的TCP端口上。为了使此防护选项起作用，它必须能够在不提供密码的情况下SSH到目标节点。因此，还必须配置dfs.ha.fencing.ssh.private-key-files选项，该选项是以逗号分隔的SSH私钥文件列表。例如：

        <property>
      <name>dfs.ha.fencing.methods</name>
      <value>sshfence</value>
    </property>

    <property>
      <name>dfs.ha.fencing.ssh.private-key-files</name>
      <value>/home/exampleuser/.ssh/id_rsa</value>
    </property>

    可选地，可以配置非标准用户名或端口以执行SSH。还可以为SSH配置超时（以毫秒为单位），之后将认为此防护方法已失败。它可能配置如下：

    <property>
  <name>dfs.ha.fencing.methods</name>
  <value>sshfence([[username][:port]])</value>
</property>
<property>
  <name>dfs.ha.fencing.ssh.connect-timeout</name>
  <value>30000</value>
</property>

    shell - 运行任意shell命令以阻止Active NameNode

    所述壳击剑方法运行的任意外壳命令。它可能配置如下：

    <property>
  <name>dfs.ha.fencing.methods</name>
  <value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
</property>

    '('和')'之间的字符串直接传递给bash shell，可能不包含任何右括号。

    shell命令将在环境设置为包含所有当前Hadoop配置变量的情况下运行，其中'_'字符替换任何'。'。配置键中的字符。使用的配置已经将任何特定于名称节点的配置提升为其通用格式 - 例如，dfs_namenode_rpc-address将包含目标节点的RPC地址，即使配置可能将该变量指定为dfs.namenode.rpc-address.ns1 .nn1。

    此外，还提供了以下涉及要隔离的目标节点的变量：

      
    $ target_host要隔离的节点的主机名
    $ target_port要隔离的节点的IPC端口
    $ TARGET_ADDRESS以上两种，合并为主机：端口
    $ target_nameserviceid要隔离的NN的名称服务ID
    $ target_namenodeid要隔离的NN的namenode ID

    这些环境变量也可以用作shell命令本身的替换。例如：

    <property>
  <name>dfs.ha.fencing.methods</name>
  <value>shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)</value>
</property>

    如果shell命令返回退出代码0，则确定防护成功。如果它返回任何其他退出代码，则防护不成功，将尝试列表中的下一个防护方法。

    注意：此防护方法不会实现任何超时。如果需要超时，则应该在shell脚本本身中实现它们（例如，通过分配子shell以在几秒钟内终止它的父节点）。

  • fs.defaultFS - Hadoop FS客户端在没有给出时使用的默认路径前缀

    （可选）您现在可以配置Hadoop客户端的默认路径以使用新的启用HA的逻辑URI。如果您之前使用“mycluster”作为名称服务ID，那么这将是所有HDFS路径的权限部分的值。这可以在您的core-site.xml文件中进行如下配置：

    <property>
  <name>fs.defaultFS</name>
  <value>hdfs://mycluster</value>
</property>

部署细节

在设置了所有必要的配置选项后，必须首先同步两个HA NameNodes的磁盘元数据。

  • 如果要设置新的HDFS集群，则应首先在其中一个NameNode上运行format命令（hdfs namenode -format）。

  • 如果您已经格式化了NameNode，或者正在将启用了HA的群集转换为启用HA，则现在应该通过运行命令“ hdfs namenode ”将NameNode元数据目录的内容复制到其他未格式化的NameNode上。 bootstrapStandby“在未格式化的NameNode上。运行此命令还将确保共享编辑目录（由dfs.namenode.shared.edits.dir配置）包含足够的编辑事务，以便能够启动两个NameNode。

  • 如果要将非HA NameNode转换为HA，则应运行命令“ hdfs -initializeSharedEdits ”，该命令将使用来自本地NameNode编辑目录的编辑数据初始化共享编辑目录。

此时，您可以像通常启动NameNode一样启动所有HA NameNode。

您可以通过浏览到配置的HTTP地址，分别访问每个NameNodes的网页。您应该注意到，配置的地址旁边将是NameNode的HA状态（“待机”或“活动”）。每当HA NameNode启动时，它最初处于待机状态。

管理命令

现在您的HA NameNode已配置并启动，您将可以访问一些其他命令来管理HA HDFS集群。具体来说，您应该熟悉“ hdfs haadmin ”命令的所有子命令。在没有任何其他参数的情况下运行此命令将显示以下用法信息：

Usage: DFSHAAdmin [-ns <nameserviceId>]
    [-transitionToActive <serviceId>]
    [-transitionToStandby <serviceId>]
    [-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
    [-getServiceState <serviceId>]
    [-getAllServiceState]
    [-checkHealth <serviceId>]
    [-help <command>]

本指南介绍了每个子命令的高级用法。有关每个子命令的特定用法信息，您应该运行“ hdfs haadmin -help <command >”。

  • transitionToActive和transitionToStandby - 将给定NameNode的状态转换为Active或Standby

    这些子命令使给定的NameNode分别转换为Active或Standby状态。这些命令不会尝试执行任何防护，因此很少使用。相反，人们几乎总是喜欢使用“ hdfs haadmin -failover ”子命令。

  • 故障转移 - 在两个NameNode之间启动故障转移

    此子命令导致从第一个提供的NameNode到第二个NameNode的故障转移。如果第一个NameNode处于Standby状态，则此命令只是将第二个NameNode转换为Active状态而不会出现错误。如果第一个NameNode处于活动状态，将尝试将其正常转换为待机状态。如果失败，将按顺序尝试防护方法（由dfs.ha.fencing.methods配置），直到成功为止。只有在此过程之后，第二个NameNode才会转换为Active状态。如果没有防护方法成功，则第二个NameNode将不会转换为活动状态，并且将返回错误。

  • getServiceState - 确定给定的NameNode是Active还是Standby

    连接到提供的NameNode以确定其当前状态，适当地将“待机”或“活动”打印到STDOUT。此子命令可能由cron作业或监视脚本使用，这些脚本需要根据NameNode当前是活动还是待机而表现不同。

  • getAllServiceState - 返回所有NameNode的状态

    连接到已配置的NameNodes以确定当前状态，适当地将“待机”或“活动”打印到STDOUT。

  • checkHealth - 检查给定NameNode的运行状况

    连接到提供的NameNode以检查其运行状况。NameNode能够对自身执行某些诊断，包括检查内部服务是否按预期运行。如果NameNode是健康的，则此命令将返回0，否则返回非零。可以使用此命令进行监视。

    注意：这尚未实现，并且除非给定的NameNode完全关闭，否则目前将始终返回成功。

自动故障转移

介绍

以上部分介绍了如何配置手动故障转移。在该模式下，即使活动节点发生故障，系统也不会自动触发从活动状态到备用NameNode的故障转移。本节介绍如何配置和部署自动故障转移。

组件

自动故障转移为HDFS部署添加了两个新组件：ZooKeeper仲裁和ZKFailoverController进程（缩写为ZKFC）。

Apache ZooKeeper是一种高可用性服务，用于维护少量协调数据，通知客户端该数据的更改以及监视客户端是否存在故障。自动HDFS故障转移的实现依赖于ZooKeeper来实现以下功能：

  • 故障检测 - 集群中的每个NameNode计算机都在ZooKeeper中维护一个持久会话。如果计算机崩溃，ZooKeeper会话将过期，通知另一个NameNode应该触发故障转移。

  • Active NameNode选举 - ZooKeeper提供了一种简单的机制，可以将节点专门选为活动节点。如果当前活动的NameNode崩溃，则另一个节点可能在ZooKeeper中采用特殊的独占锁，指示它应该成为下一个活动的。

ZKFailoverController（ZKFC）是一个新组件，它是一个ZooKeeper客户端，它还监视和管理NameNode的状态。运行NameNode的每台机器也运行ZKFC，ZKFC负责：

  • 运行状况监视 - ZKFC定期使用运行状况检查命令对其本地NameNode进行ping操作。只要NameNode及时响应健康状态，ZKFC就认为该节点是健康的。如果节点已崩溃，冻结或以其他方式进入不健康状态，则运行状况监视器会将其标记为运行状况不佳。

  • ZooKeeper会话管理 - 当本地NameNode运行正常时，ZKFC在ZooKeeper中保持会话打开。如果本地NameNode处于活动状态，它还拥有一个特殊的“锁定”znode。此锁使用ZooKeeper对“短暂”节点的支持; 如果会话过期，将自动删除锁定节点。

  • 基于ZooKeeper的选举 - 如果本地NameNode是健康的，并且ZKFC发现没有其他节点当前持有锁znode，它将自己尝试获取锁。如果成功，那么它“赢得了选举”，并负责运行故障转移以使其本地NameNode处于活动状态。故障转移过程类似于上述手动故障转移：首先，必要时对先前的活动进行隔离，然后本地NameNode转换为活动状态。

有关自动故障转移设计的更多详细信息，请参阅Apache HDFS JIRA上附加到HDFS-2185的设计文档。

部署ZooKeeper

在典型部署中，ZooKeeper守护程序配置为在三个或五个节点上运行。由于ZooKeeper本身具有轻量级资源要求，因此可以在与HDFS NameNode和备用节点相同的硬件上并置ZooKeeper节点。许多运营商选择在与YARN ResourceManager相同的节点上部署第三个ZooKeeper进程。建议将ZooKeeper节点配置为将数据存储在与HDFS元数据不同的磁盘驱动器上，以获得最佳性能和隔离。

ZooKeeper的设置超出了本文档的范围。我们假设您已经设置了在三个或更多节点上运行的ZooKeeper集群，并通过使用ZK CLI进行连接来验证其正确的操作。

在你开始之前

在开始配置自动故障转移之前，应关闭群集。当群集运行时，目前无法从手动故障转移设置转换为自动故障转移设置。

配置自动故障转移

自动故障转移的配置需要在配置中添加两个新参数。在hdfs-site.xml文件中，添加：

<property>
   <name>dfs.ha.automatic-failover.enabled</name>
   <value>true</value>
 </property>

这指定应设置群集以进行自动故障转移。在您的core-site.xml文件中，添加：

 <property>
   <name>ha.zookeeper.quorum</name>
   <value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
 </property>

这列出了运行ZooKeeper服务的主机端口对。

与本文档前面所述的参数一样，这些设置可以通过使用名称服务ID后缀配置密钥来基于每个名称进行配置。例如，在启用了联合的群集中，您可以通过设置dfs.ha.automatic-failover.enabled.my-nameservice-id，仅为其中一个名称服务显式启用自动故障转移。

还可以设置其他几个配置参数来控制自动故障转移的行为; 但是，大多数安装都不需要它们。有关详细信息，请参阅配置密钥特定文档。

在ZooKeeper中初始化HA状态

添加配置密钥后，下一步是在ZooKeeper中初始化所需的状态。您可以通过从其中一个NameNode主机运行以下命令来执行此操作。

[hdfs]$ $HADOOP_HOME/bin/zkfc -formatZK

这将在ZooKeeper中创建一个znode，其中自动故障转移系统存储其数据。

使用start-dfs.sh启动集群

由于配置中已启用自动故障转移，因此start-dfs.sh脚本现在将在运行NameNode的任何计算机上自动启动ZKFC守护程序。当ZKFC启动时，它们将自动选择其中一个NameNode变为活动状态。

手动启动集群

如果手动管理群集上的服务，则需要在运行NameNode的每台计算机上手动启动zkfc守护程序。您可以通过运行以下命令来启动守护程序：

[hdfs]$ $HADOOP_HOME/bin/hdfs --daemon start zkfc

保护对ZooKeeper的访问

如果您正在运行安全群集，则可能需要确保ZooKeeper中存储的信息也是安全的。这可以防止恶意客户端修改ZooKeeper中的元数据或可能触发错误的故障转移。

为了保护ZooKeeper中的信息，首先将以下内容添加到core-site.xml文件中：

 <property>
   <name>ha.zookeeper.auth</name>
   <value>@/path/to/zk-auth.txt</value>
 </property>
 <property>
   <name>ha.zookeeper.acl</name>
   <value>@/path/to/zk-acl.txt</value>
 </property>

请注意这些值中的“@”字符 - 这指定配置不是内联的，而是指向磁盘上的文件。身份验证信息也可以通过CredentialProvider读取（请参阅hadoop-common项目中的CredentialProviderAPI指南）。

第一个配置的文件指定ZooKeeper身份验证列表，格式与ZK CLI使用的格式相同。例如，您可以指定以下内容：

digest:hdfs-zkfcs:mypassword

...其中hdfs-zkfcs是ZooKeeper的唯一用户名，mypassword是一些用作密码的唯一字符串。

接下来，使用如下命令生成与此身份验证对应的ZooKeeper ACL：

[hdfs]$ java -cp $ZK_HOME/lib/*:$ZK_HOME/zookeeper-3.4.2.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider hdfs-zkfcs:mypassword
output: hdfs-zkfcs:mypassword->hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs=

将此输出的部分复制并粘贴到“ - >”字符串后面的zk-acls.txt文件中，前缀为字符串“ digest： ”。例如：

digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

为了使这些ACL生效，您应该重新运行zkfc -formatZK命令，如上所述。

执行此操作后，您可以从ZK CLI验证ACL，如下所示：

[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa

验证自动故障转移

设置自动故障转移后，应测试其操作。为此，请首先找到活动的NameNode。您可以通过访问NameNode Web界面来确定哪个节点处于活动状态 - 每个节点在页面顶部报告其HA状态。

找到活动的NameNode后，可能会导致该节点出现故障。例如，您可以使用kill -9 <PID of NN >来模拟JVM崩溃。或者，您可以重启机器或拔掉网络接口以模拟不同类型的停机。触发您希望测试的中断后，另一个NameNode应在几秒钟内自动激活。检测故障并触发故障转移所需的时间取决于ha.zookeeper.session-timeout.ms的配置，但默认为5秒。

如果测试不成功，则可能是配置错误。检查日志以查找zkfc守护程序以及NameNode守护程序，以便进一步诊断问题。

自动故障转移常见问题

  • 以任何特定顺序启动ZKFC和NameNode守护进程是否重要？

    在任何给定节点上，您可以在其对应的NameNode之前或之后启动ZKFC。

  • 我应该采取哪些额外的监测措施？

    您应该在运行NameNode的每个主机上添加监视，以确保ZKFC仍在运行。例如，在某些类型的ZooKeeper故障中，ZKFC可能会意外退出，应重新启动以确保系统已准备好进行自动故障转移。

    此外，您应该监视ZooKeeper仲裁中的每个服务器。如果ZooKeeper崩溃，则自动故障转移将不起作用。

  • 如果ZooKeeper出现故障会怎样？

    如果ZooKeeper集群崩溃，则不会触发自动故障转移。但是，HDFS将继续运行而不会产生任何影响。重新启动ZooKeeper时，HDFS将重新连接，没有任何问题。

  • 我可以将我的一个NameNode指定为主要/首选吗？

    不。目前，这不受支持。无论哪个NameNode首先启动都将变为活动状态。您可以选择以特定顺序启动集群，以便首选节点启动。

  • 如何配置自动故障转移时启动手动故障转移？

    即使配置了自动故障转移，您也可以使用相同的hdfs haadmin命令启动手动故障转移。它将执行协调的故障转移。

 

 

 

原文链接: https://hadoop.apache.org/docs/r3.2.0/

Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生