专栏首页Hadoop实操0779-5.14.4-HMaster无法成为Active异常分析

0779-5.14.4-HMaster无法成为Active异常分析

故障描述

1.1发生背景

很久很久以前,有一天,我在HBase中新建了一张表 “XXX: XXX _EXCEPTION_LIST_INFO”,同时HBase在处理大量更新操作。然后在DROP掉表XXX: XXX_EXCEPTION_LIST_INFO时,HBase Master就宕机。

之后通过CM重新启动后HBase服务,服务重启后发生如下两个错误,导致HBase集群无法正常恢复:(1)HMaster节点自动Active失败;(2)大量Region出现offline和RIT。

1.2现象描述

HA HMaster节点启动了,过一段时间Active HBase Master节点自动失败(大概3~5分钟)。因为集群采用了HA高可用,因此Standby HBase Master节点自动切换为Active。再过差不多相同时间,该节点也自动失败。

查看Master节点的日志报错如下

Failed to become active master java.io.IOException: Timedout 300000ms waiting for namespace table to be assigned

Master Web UI上显示处于RIT的Region

Master状态页告警信息:

Found regions staying in transition state for a duration longer than the configured threshold in HBase.

故障分析处理

1.Master的日志报错:Timeout 300000ms waiting for namespace table to be assigned.表示namespace表未分配,并且超过设置的时间阈值。在HBase的设计中,Master启动时首先分配meta表,然后再分配其它表。系统表hbase:namespace和其它用户表分配时同等对待,并没有先分配系统表再分配用户表,如果一个集群region非常多,默认300000ms(5分钟)还分配不到namespace表,此时需要修改hbase.master.namespace.init.timeout超时时间。

2.根据此时情况,通过CM在“hbase-site.xml的HBase服务高级配置代码段(安全阀)”中增加以下配置:

<property>
<name>hbase.master.namespace.init.timeout</name>
<value>86400000</value>
</property>
<property>
<name>hbase.master.initializationmonitor.timeout</name>
<value>86400000</value>
</property>

即增加namespace表分配超时时间为1天。

修改完成之后重启HBase服务,这里选择滚动重启HBase时RegionServer无法重启,所以选择完成重启HBase服务。

3.重启完成后,Master依然告警:Found regions staying in transition state for a duration longer than the configured threshold in HBase.,但服务并未宕掉,Master告警提示的原因是在HBase Master启动时,检测到有Region长时间处于RIT状态(超过阈值)。

查看Master日志如下

大量Region处于PENDING_OPEN状态,Master检测到RIT,

查看Zookeeper中的/hbase/region-in-transition,也可以看到大量的Region。

说明:每次HBase Master对Region的一个OPEN或一个CLOSE操作都会向Master 的RIT列表中插入一条记录,因为Master对Region的操作要保持原子性。Region的 OPEN和 CLOSE是通过HBase Master和 RegionServer 协助来完成的。为了满足这些操作的协调、回滚、一致性,HBase Master采用了 RIT 机制并结合Zookeeper 中znode状态来保证操作的安全和一致性。

Region有以下几种状态:

  • OFFLINE:region is in an offline state
  • PENDING_OPEN:sent rpc to server to open but has not begun
  • OPENING:server has begun to open but not yet done
  • OPEN:server opened region and updated meta
  • PENDING_CLOSE:sent rpc to server to close but has not begun
  • CLOSING:server has begun to close but not yet done
  • CLOSED:server closed region and updated meta
  • SPLITTING:server started split of a region
  • SPLIT:server completed split of a region

在注册为active的Master Web UI上查看已上线的Region数如下:

4.经确认HBase未使用replication后,选择重建Znode的方式进行测试:

a.停止HBase服务

b.使用hbase zkcli命令进入ZK客户端

c.执行rmr /hbase清除/hbase

d.重启HBase服务,此时/hbase会重新生成

5.但是重启完之后问题依然存在,再次查看Master日志发现如下信息:

6.查看RegionServer的日志,可以看到频繁出现以下错误:

由上可以看出索引表的Region is not online,查看RegionServer Web UI发现RPC线程一直处于Initializing Region的Replaying edits阶段,并且在等待一个小时时间后依然未完成。因此分析原因为Phoenix索引表的Region不能online,导致数据表的Region构建进程卡住,但是这些构建进程占用了openregion线程(默认3个),导致索引表不能正常openregion,产生死锁。

因此需要调整hbase.regionserver.executor.openregion.threads参数以增加openregion线程数。

7.通过CM在“hbase-site.xml的HBase服务高级配置代码段(安全阀)”中增加以下配置:

<property>
<name>hbase.regionserver.executor.openregion.threads</name>
<value>200</value>
</property>

即增加Region分配线程数至200个,然后再次重启HBase服务

重启HBase服务, HBase Master仍有告警信息,但在Active Master Web UI上可以看到上线的Region数量在增加,同时RIT中的Region数量在减少。稍等片刻后HBase服务恢复正常。

经测试HBase可以正常提供服务,数据无丢失。

处理结论

1.HBase Master在启动时会首先分配meta表的Region,然后再分配其它表。namespace表和user表分配时同等对待,并没有先分配系统表再分配用户表,如果一个集群Region非常多,默认300000ms(5分钟)有可能还分配不到namespace表,此时抛出异常:Failed to become active master java.io.IOException: Timedout 300000ms waiting for namespace table to be assigned。此时需要调整参数hbase.master.namespace.init.timeout增加超时时间。

2.分布式死锁发生在使用Phoenix(4.14.1)构建二级索引,并且数据表、二级索引表的Region数量适中的集群中。当RegionServer打开Phoenix数据表的一个Region时,它将为该Region执行WAL重播,并重新构建二级索引表,而数据表的Region分配依赖于二级索引表。默认情况下每个RS上只有一个线程池,包含三个openregion线程。而二级索引表和数据表共用同一个线程池。因此,当Phoenix数据表的Region的这些重建进程占用了openregion线程时,二级索引表就只能进入队列等候,其Region就不能online。这就是死锁发生的原因。

解决方式可以在hbase-site.xml中修改以下参数:

1)设置hbase.master.startup.retainassign为false(默认为true)

2)增加hbase.regionserver.executor.openregion.threads 的值(默认为3),然后重启集群解决。

如果还是出现同样问题,可以调优以下分配管理器参数,以匹配Region的数量,从而加快分配速度:

  • hbase.assignment.threads.max:线程池大小,默认值30
  • hbase.master.namespace.init.timeout:默认值300000ms
  • hbase.master.wait.on.regionservers.mintostart:向HMaster汇报的RegionServer的数量最小启动值,默认值1
  • hbase.bulk.assignment.threshold.regions:Region数量超过阈值(默认值7),使用bulk assign
  • hbase.bulk.assignment.threshold.servers :Server数量超过阈值(默认值3),使用bulk assign

参考链接:

https://issues.apache.org/jira/browse/PHOENIX-3072

https://issues.apache.org/jira/browse/HBASE-16095

https://docs.cloudera.com/documentation/enterprise/release-notes/topics/cdh_rn_phoenix_ki.html#concept_xdx_1wq_dq

本文分享自微信公众号 - Hadoop实操(gh_c4c535955d0f),作者:Fayson

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-06-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 由MasterProcWals状态日志过多导致的HBase Master重启失败问题

    本文主要讲述如何解决由MasterProcWals状态日志过多导致的HBase Master重启失败问题。

    Fayson
  • 0713-6.2.0-HBase的Thrift Server启动问题

    配置Hue集成HBase的过程中,添加角色实例HBase Thrift Server后,把HBase Thrift身份验证(hbase.thrift.secur...

    Fayson
  • 0783-6.2.0-如何在Hue中集成HBase

    Fayson在前面介绍了《0635-5.16.1-Hue集成HBase出现Api Error异常分析》和《0647-6.1.1-Hue集成HBase出现Api ...

    Fayson
  • HBase 伪分布式模式安装与启动

    安装 HBase 之前默认我们已经完成了 Hadoop、ZooKeeper 安装,如果还没有安装可以参考如下博文:

    smartsi
  • HBase集群搭建与调优(持续更新)

    天策
  • ZooKeeper 笔记(5) ACL(Access Control List)访问控制列表

    zk做为分布式架构中的重要中间件,通常会在上面以节点的方式存储一些关键信息,默认情况下,所有应用都可以读写任何节点,在复杂的应用中,这不太安全,ZK通过ACL机...

    菩提树下的杨过
  • 前端新人,如何找一个师傅?

    如题,这应该是许多前端新人都想得到的,就是找一个师傅。 想找到这样一个人,有不懂的时候随时可以问,有迷茫的时候随时可以请教,有牢骚的时候随时可以倾诉,手把手的教...

    web前端教室
  • Git:一款比付费主题更像是付费主题的WordPress免费主题

    神无月
  • webpack设置自定义环境变量以区分打包后不同环境不同输出

    你有没有遇到过这样的情况!比如你们有四种(或更多)环境:开发环境(本地调式代码环境)、测试环境(脏数据环境)、预生产环境(无限接近生产环境)、生产环境(正式环境...

    前端人人
  • 【CentOS】Apache多虚拟主机多版本PHP(5.3+5.6+N)共存运行配置全过程

    Eller

扫码关注云+社区

领取腾讯云代金券