常见HDFS服务级异常及处理方法

Posted 壹方城

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了常见HDFS服务级异常及处理方法相关的知识，希望对你有一定的参考价值。

HDFS editlog 损坏导致NameNode故障

现象描述

集群节点断电后恢复或者磁盘满扩容后，NameNode启动失败。

可能原因

JournalNode editlog文件损坏，各个JournalNode节点上数据不一致。

排查思路

  1. 查看NameNode日志，报错如下：2019-06-27 17:30:23,434 | FATAL | IPC Server handler 6 on 25006 | Error: recoverUnfinalizedSegments failed for required journal (JournalAndStream(mgr=QJM to [192.169.1.166:25012, 192.168.1.204:25012, 192.168.1.239:25012], stream=null)) | JournalSet.java:396 java.io.IOException: Timed out waiting 120000ms for a quorum of nodes to respond. at org.apache.hadoop.hdfs.qjournal.client.AsyncLoggerSet.waitForWriteQuorum(AsyncLoggerSet.java:138) at org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager.createNewUniqueEpoch(QuorumJournalManager.java:223) at org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager.recoverUnfinalizedSegments(QuorumJournalManager.java:459) at org.apache.hadoop.hdfs.server.namenode.JournalSet$6.apply(JournalSet.java:622) at org.apache.hadoop.hdfs.server.namenode.JournalSet.mapJournalsAndReportErrors(JournalSet.java:391) at org.apache.hadoop.hdfs.server.namenode.JournalSet.recoverUnfinalizedSegments(JournalSet.java:619) at org.apache.hadoop.hdfs.server.namenode.FSEditLog.recoverUnclosedStreams(FSEditLog.java:1611) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startActiveServices(FSNamesystem.java:1231) at org.apache.hadoop.hdfs.server.namenode.NameNode$NameNodeHAContext.startActiveServices(NameNode.java:1925) at org.apache.hadoop.hdfs.server.namenode.ha.ActiveState.enterState(ActiveState.java:61) at org.apache.hadoop.hdfs.server.namenode.ha.HAState.setStateInternal(HAState.java:65) at org.apache.hadoop.hdfs.server.namenode.ha.StandbyState.setState(StandbyState.java:59) at org.apache.hadoop.hdfs.server.namenode.NameNode.transitionToActive(NameNode.java:1768) at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.transitionToActive(NameNodeRpcServer.java:1747) at org.apache.hadoop.ha.protocolPB.HAServiceProtocolServerSideTranslatorPB.transitionToActive(HAServiceProtocolServerSideTranslatorPB.java:112) at org.apache.hadoop.ha.proto.HAServiceProtocolProtos$HAServiceProtocolService$2.callBlockingMethod(HAServiceProtocolProtos.java:5409) at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:530) at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1036) at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:928) at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:863) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1729) at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2792) 2019-06-27 17:30:23,436 | INFO | IPC Server handler 6 on 25006 | Exiting with status 1: Error: recoverUnfinalizedSegments failed for required journal (JournalAndStream(mgr=QJM to [192.169.1.166:25012, 192.168.1.204:25012, 192.168.1.239:25012], stream=null)) | ExitUtil.java:210
  2. 查看JournalNode日志中有如下日志：2019-06-27 17:33:36,354 | WARN | IPC Server handler 0 on 25012 | Caught exception after scanning through 0 ops from /srv/BigData/journalnode/hacluster/current/edits_inprogress_0000000000000000808 while determining its valid length. Position was 1028096 | FSEditLogLoader.java:1292 java.io.IOException: Can't scan a pre-transactional edit log. at org.apache.hadoop.hdfs.server.namenode.FSEditLogOp$LegacyReader.scanOp(FSEditLogOp.java:5295) at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanNextOp(EditLogFileInputStream.java:261) at org.apache.hadoop.hdfs.server.namenode.FSEditLogLoader.scanEditLog(FSEditLogLoader.java:1288) at org.apache.hadoop.hdfs.server.namenode.EditLogFileInputStream.scanEditLog(EditLogFileInputStream.java:345) at org.apache.hadoop.hdfs.server.namenode.FileJournalManager$EditLogFile.scanLog(FileJournalManager.java:566) at org.apache.hadoop.hdfs.qjournal.server.Journal.scanStorageForLatestEdits(Journal.java:234) at org.apache.hadoop.hdfs.qjournal.server.Journal.<init>(Journal.java:175) at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:106) at org.apache.hadoop.hdfs.qjournal.server.JournalNode.getOrCreateJournal(JournalNode.java:151) at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.getEditLogManifest(JournalNodeRpcServer.java:228) at org.apache.hadoop.hdfs.qjournal.protocolPB.QJournalProtocolServerSideTranslatorPB.getEditLogManifest(QJournalProtocolServerSideTranslatorPB.java:230) at org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocolProtos$QJournalProtocolService$2.callBlockingMethod(QJournalProtocolProtos.java:28984) at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:530) at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1036) at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:928) at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:863) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1729) at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2792)

操作步骤

  1. 停止HDFS服务。
  2. 确认editlog没有损坏的JournalNode。JournalNode的运行日志中无java.io.IOException: Can't scan a pre-transactional edit log错误日志，则为editlog没有损坏。
  3. 拷贝正常JournalNode上的editlog到损坏的JournalNode节点上。
  4. 重启HDFS服务，启动成功。

资源异常导致HDFS进入安全模式

现象描述

在性能环境上验证性能指标时HDFS进入安全模式。

NameNode日志中出现下列信息：

WARN org.apache.hadoop.hdfs.server.namenode.NameNodeResourceChecker: Space available on volume 'null' is 0, WARN org.apache.hadoop.hdfs.server.namenode.FSNamesystem: NameNode low on available disk space. Entering safe mode.

可能原因

  1. 参数“dfs.namenode.name.dir”配置目录的磁盘空间不足。
  2. 底层网络文件系统出现了不可用的情况导致的，如网络不稳定等。

排查思路

  1. 查看参数“dfs.namenode.name.dir”配置目录的磁盘空间是否足够。
  2. 查看底层网络文件系统是否异常，如网络不稳定等。
  3. 查看NameNode日志中是否出现类似“NameNode low on available disk space. Entering safe mode”的日志。

操作步骤

  1. 查看参数“dfs.namenode.name.dir”配置目录的磁盘空间是否足够。
  2. 修复底层网络文件系统之后（网络稳定之后），手动退出安全模式。执行hdfs dfsadmin -safemode leave命令手动退出安全模式。

NameNode一直处于双备状态，无法升主

现象描述

管控服务界面，NameNode一直处于双“standby”状态，无法提供服务。

可能原因

  • Zookeeper中残留控制NameNode主备状态的旧数据，导致NameNode主备选举失败。
  • ZooKeeper客户端ZKFC与ZooKeeper服务端连接的sessionID不一致，导致连接处于死锁状态。
  • JournalNode出现异常导致NameNode主备发生倒换，NameNode在恢复editlog过程中发生同步editlog失败。

排查思路

  • 在ZKFC的日志中，如果存在类似“java.lang.IllegalArgumentException: Unable to determine service address for namenode '1781'”信息，则可以判断是由于Zookeeper中残留旧数据造成的。
  • 在两个ZKFC的日志中，如果存在“主 > 备”和“备 > 主 > 备”的NameNode状态倒换的情况出现，则可以判断ZooKeeper客户端ZKFC与ZooKeeper服务端连接处于死锁状态。
  • NameNode出现写editlog失败和恢复editlog失败。
  • 1.状态为“主”的NameNode的日志中出现错误信息：Got too many exceptions to achieve quorum size 2/3.可以判断发生了写editlog失败，NameNode将会重启，存在NameNode状态“主 > 备”的倒换。
  • 2.状态为“备”的NameNode的日志中出现错误信息：recoverUnfinalizedSegments failed for required journal可以判断发生了NameNode恢复editlog失败，NameNode将会重启导致抢占“主”状态失败，此NameNode状态一直处于“备”。

操作步骤

  • Zookeeper中残留旧数据的处理。
    1. 以root用户登录ZooKeeper客户端所在的节点。请参考“软件安装”中“安装客户端”章节安装Zookeeeper客户端。
    2. 执行如下命令，导出环境变量cd zookeeper客户端的安装目录source bigdata_env
    3. 安全模式下，执行以下命令，使用hdfs用户登录Kerberos（普通模式下请跳过此步骤）。kinit hdfshdfs用户的默认密码信息请参见《MapReduce Service 3.1.2-ESL 帐户一览表》或咨询系统管理员。
    4. 使用ZooKeeper客户端，进入命令行模式。zkCli.sh -server Zookeeper任一健康节点的业务IP:24002
    5. 执行以下命令，删除旧数据。deleteall /hadoop-ha/hacluster/ActiveBreadCrumb
    6. 查看NameNode的主备状态是否恢复正常。
  • ZooKeeper客户端与服务端连接处于死锁状态。
    1. 登录FusionInsight Manager界面，选择“集群 > 待操作集群的名称 > 服务> HDFS > 实例 > NameNode”，选中状态为“备 > 主 > 备”的NameNode。
    2. 选择“更多 > 重启实例”，重启该NameNode。
  • NameNode出现写editlog失败和恢复editlog失败。对两个NameNode的节点分别进行以下操作以恢复editlog。
    1. 在管控界面中停止HDFS服务。
    2. 以root用户登录新的NameNode节点，执行su - hdfs
    3. xxxxxx（待补充）
    4. 运行如下命令恢复editlog。cd $HADOOP_HOME/bin./hdfs namenode -recover
    5. 根据提示输入“y”后完成操作。
    6. 在FusionInsight Manager界面中启动HDFS服务。

HDFS安全模式无法退出

现象描述

  • HDFS进入安全模式，HDFS服务不可用。
  • 安全模式无法自动恢复。

可能原因

  • 数据节点硬盘故障，或节点故障可能导致数据副本丢失。
  • HDFS在如下情况进入安全模式：HDFS block丢失的阈值过高。在前面情况发生后，HDFS进入SafeMode。HDFS需要一个很长的时间和特定条件来退出SafeMode。
    1. 当NameNode启动且等待DataNode上报副本。
    2. NameNode所在磁盘空间不足。
  • HDFS对应文件的副本全部丢失。

排查思路

  1. 检查FusionInsight Manager界面是否有节点、硬盘故障告警。
  2. 检查NameNode的块丢失阈值“dfs.namenode.safemode.threshold-pct”是否配置过高，默认值为“0.999999”。
  3. 检查安全模式退出命令是否使用正确。

操作步骤

  1. 参照HDFS块丢失异常进行恢复操作。
  2. 参照常用指导中安全模式操作指导进行安全模式的退出操作。
  3. 检查NameNode所在磁盘空间使用情况，并恢复。

参考信息

HDFS退出安全模式的方法请参见Apache Hadoop 3.1.1 – Hadoop Commands Guide。

HDFS服务一直异常

现象描述

HDFS服务界面显示服务不可用（红色），HBase、Hive、Mapreduce等服务。都会受影响

可能原因

  • HDFS进入安全模式。
  • HDFS依赖的ZooKeeper服务异常。

排查思路

  1. 检查HDFS是否处于安全模式。
  2. 检查ZooKeeper服务是否运行正常。

操作步骤

  1. 确认HDFS是否处于安全模式。
    • 是，直接退出HDFS的安全模式。
    • 否，执行步骤 2。
  1. 登录FusionInsight Manager管理界面，在ZooKeeper的服务页面，检查服务是否正常，并在“运维 > 告警 > 告警”页面检查是否有ZooKeeper服务的故障告警。
  2. 按照ZooKeeper的告警指导，恢复服务，并确保ZooKeeper服务正常。
  3. ZooKeeper服务正常后，尝试重启HDFS服务，并检查是否正常。
    • 是，操作结束。
    • 否，执行步骤 5。
  1. 检查NameNode是否故障，并尝试修复。

参考信息

HDFS退出安全模式的方法请参见Apache Hadoop 3.1.1 – Hadoop Commands Guide。

以上是关于常见HDFS服务级异常及处理方法的主要内容，如果未能解决你的问题，请参考以下文章

HDFS简介及相关概念

hdfs深入：08hdfs的JavaAPI以及如何解决winutils的问题

HDFS基本架构原理与应用场景实践（附ppt）

HDFS的Java接口及常用API

Hadoop系列之HDFS架构

字节跳动 EB 级 HDFS 实践