HBase集群出现NotServingRegionException问题的排查及解决方法

HBase集群在读写过程中,可能由于Region Split或Region Blance等导致Region的短暂下线,此时客户端与HBase集群进行RPC操作时会抛出NotServingRegionException异常,从而导致读写操作失败。这里根据实际项目经验,详细描述这一问题的发现及排查解决过程。

1. 发现问题

在对HBase集群进行压力测试过程中发现,当实际写入HBase和从HBase查询的量是平时的若干倍时(集群规模10~20台,每秒读写数据量在几十万条记录的量级),导致集群的读写出现一定程度的波动。具体如下:

1)写端抛出以下异常信息:

org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 150 actions: NotServingRegionException: 150 times, servers with issues: my161208.cm6:60020,

at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatchCallback(HConnectionManager.java:1600)

at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatch(HConnectionManager.java:1376)

at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:916)

2)读端也抛出类似异常信息:

org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after attempts=10, exceptions:

Mon Oct 29 14:03:09 CST 2012, org.apache.hadoop.hbase.client.ScannerCallable@3740fb20, org.apache.hadoop.hbase.NotServingRegionException: org.apache.hadoop.hbase.NotServingRegionException: xxxxxx,\x0FP\x8D\xC3\xDB1053223266:\x00\x00V6,1351490475989.bd68113129f07163dc25e78fba17ad6c. is closing

以上异常,在压测期间周期性地出现,HBase集群由此出现了短暂的不可服务期。

2. 排查问题

通过查看HBase Master运行日志,结合客户端抛出异常的时刻,发现当时HBase集群内正在进行Region的Split和不同机器之间的Region Balance,那么,为什么会周期性频繁触发以上过程呢?而且是发生在压测期间(数据量与平时相比大几倍)。下面结合表的设计来分析一下:

1)由于表中rowkey有时间字段,因此每天都需要新创建Region,同时由于写入数据量大,进一步触发了HBase的Region Split操作,这一过程一般耗时较长(测试时从线上日志来看,平均为10秒左右,Region大小为4GB),且Region Split操作触发较为频繁;

2)同时由于Region Split操作导致Region分布不均匀,进而触发HBase自动做Region Balance操作,Region迁移过程中也会导致Region下线,这一过程耗时较长(测试时从线上日志来看,平均为20秒左右)。

3. 解决问题

首先,从客户端考虑,其实就是要保证Region下线不可服务期间,读写请求能够在集群恢复后继续,具体可以采取如下措施:

1)对于写端,可以将未写入成功的记录,添加到一个客户端缓存中,隔一段时间后交给一个后台线程统一重新提交一次;也可以通过setAutoFlush(flase, false)保证提交失败的记录不被抛弃,留在客户端writeBuffer中等待下次writeBuffer满了后再次尝试提交,直到提交成功为止。

2)对于读端,捕获异常后,可以采取休眠一段时间后进行重试等方式。

更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/extra/

3)当然,还可以根据实际情况合理调整hbase.client.retries.number和hbase.client.pause配置选项。

然后,从服务端考虑,需要分别针对Region Split和Region Balance进行解决:

1)由于建表时,我们已经考虑到了数据在不同Region Server上的均匀分布,而且预先在不同Region Server上创建并分配了相同数目的Region,那么考虑到为了集群能够在实际线上环境下提供稳定的服务,可以选择关掉HBase的Region自动Balance功能,当然关掉后可以选择在每天读写压力小的时候(如凌晨后)触发执行一次Balance操作即可。

2)接下来,Region总是被创建,不能被复用的问题该如何解决呢?根本原因是rowkey中包含了timestamp字段,而每时每刻timestamp总是向上增长的。但是,使用方确实需要能够根据timestamp字段进行顺序scan操作,因此,timestamp字段必须保留。据此,这里给出两种解决思路:

一种常用方法是将表按照时间分表,例如按天进行分表,这样可以通过预先建表创建好Region分区,避免实际读写过程中频繁触发Region Split等过程,但是这一方法的缺点是每天需要预先建好表,而这一DDL过程可能出现问题进而导致读写出现问题,同时跨天时读写端也需要做出适应,调整为读写新创建的表。

其实,我们可以换一种思路,通过修改表的rowkey结构,将timestamp字段改成一个周期循环的timestamp,如取timestamp % TS_MODE后的值,其中TS_MODE须大于等于表的TTL时间周期,这样才能保证数据不会被覆盖掉。经过这样改造后,即可实现Region的复用,避免Region的无限上涨。对于读写端的变更也较小,读写端操作时只需将timestamp字段取模后作为rowkey进行读写,另外,读端需要考虑能适应scan扫描时处理[startTsMode, endTsMode]和[endTsMode, startTsMode]两种情况。

4. 总结的话

以上仅是本人结合实际项目中遇到的问题进行了概括总结,仅供参考。欢迎讨论交流。

作者: 大圆那些事

网址: http://www.cnblogs.com/panfeng412/archive/2012/11/04/hbase-how-to-resolve-not-serving-region-exception.html

时间: 2024-01-15 20:45:39

HBase集群出现NotServingRegionException问题的排查及解决方法的相关文章

高可用Hadoop平台-HBase集群搭建

1.概述 今天补充一篇HBase集群的搭建,这个是高可用系列遗漏的一篇博客,今天抽时间补上,今天给大家介绍的主要内容目录如下所示: 基础软件的准备 HBase介绍 HBase集群搭建 单点问题验证 截图预览 那么,接下来我们开始今天的HBase集群搭建学习. 2.基础软件的准备 由于HBase的数据是存放在HDFS上的,所以我们在使用HBase时,确保Hadoop集群已搭建完成,并运行良好.若是为搭建Hadoop集群,请参考我写的<配置高可用的Hadoop平台>来完成Hadoop平台的搭建.另

hbase 集群启动后master 端口监听不正确

问题描述 hbase 集群启动后master 端口监听不正确 截图是在master机器上端口监听,可以看到60000.60020是监听在127.0.0.1上的 这样就导致其他的slave 机器无法访问60000.60020端口,网上说是hosts配置不正确,但是都各种修改了还是不正确,请问该如何解决

E-MapReduce的HBase集群使用Hue

E-MapReduce产品的emr-2.0.0以下的版本创建的HBase集群,实现Hue访问HBase步骤如下: 1. 启动HBase thrift(emr集群的master节点) >su -l hdfs -c '/opt/apps/hbase-1.1.1/bin/hbase thrift start >/dev/null 2>&1 &' 2.安装Hue(本地或者emr集群的master节点) 备注:对于emr-2.0.0版本的集群,Hue已经安装,忽略步骤2. 下面以在

如何访问E-MapReduce中HBase集群

一.创建HBase集群 E-MapReduce在EMR-1.2.0版本开始支持HBase(1.1.1)了,创建集群时注意点如下: 1)选择付费类型 创建集群的基本信息页面可选择付费类型,包括包年包月和按量付费两种,一般HBase集群都是长期存在的,所以选择包年包月价格更实惠. 2)选择软件版本配置 产品版本选择EMR-1.2.0及以上版本,集群类型选择HBASE,目前EMR支持的HBase版本号为1.1.1. 3)集群网络配置 可以选择将HBase集群创建在经典网络环境或者专有网络环境(VPC)

青云QingCloud推出HBase集群服务 支持SQL等高级功能

为了更好地满足用户对大数据基础平台的需求,企业级基础云服务商青云QingCloud(qingcloud.com)日前宣布正式推出HBase集群服务,包含HBase数据库服务.HDFS分布式文件系统.Phoenix查询引擎三大组件.在原生HBase的基础上,QingCloud在配置的易用性.监控告警.在线伸缩等方面进行全面优化,并支持二级索引.SQL和JDBC API,以及完全ACID事务等高级功能,用户能够在2-3分钟内创建一个HBase集群,并能够在控制台直接修改配置文件并应用,极大地减轻了H

HBase 集群监控

为什么需要监控? 为了保证系统的稳定性,可靠性,可运维性. 掌控集群的核心性能指标,了解集群的性能表现. 集群出现问题时及时报警,便于运维同学及时修复问题. 集群重要指标值异常时进行预警,将问题扼杀在摇篮中,不用等集群真正不可用时才采取行动. 当集群出现问题时,监控系统可以帮助我们更快的定位问题和解决问题 如何构建 HBase 集群监控系统? 公司有自己的监控系统,我们所要做的就是将 HBase 中我们关心的指标项发送到监控系统去,问题就转换为我们开发,采集并返回哪些 HBase 集群监控指标项

我为什么建议自建HBase集群应该迁移过来?

引言 最近云HBase商业化了,HBase在业界应用还是比较广泛.在云上环境下中,不少客户都自建了HBase集群,还有一部分用户是把HBase集群放在Hadoop离线集群内部.此文主要对比下云HBase数据库跟自建HBase的差异.另外,在成本上,云HBase数据库跟自建基本差不多,目前云HBase在推广打折阶段,比自建还便宜不少 自建HBase与ApsaraDB HBase对比 自建目前在云上,基本是基于ecs去自己构建,ApsaraDB HBase我们还是做了不少事情的: ApsaraDB

HBase集群管理

通过之前文章的描述,我们已经有能力设计并部署搭建HBase集群了 当我们的HBase集群开始运行的时候,新的挑战又来了 例如,我们可能会遇到在集群运行的时候添加或者删除节点 又或者需要拷贝/备份整个集群的数据等等 如何在集群运行的时候以最小的代价来执行这些操作呢? 下面总结一下HBase集群的相关运维和管理知识点 运维任务 添加/删除节点 在HBase中动态添加/删除节点非常简单,只需要一些命令操作即可,HBase会自动帮你处理节点上下线需要做的事情 添加节点 1.修改conf目录下的regio

E-MapReduce的HBase集群间迁移

HBase集群间数据迁移 0. 前置 HBase集群 HDFS Cluster-A hdfs:/A Cluster-B hdfs:/B Cluster-A集群数据迁移到Cluster-B 1. Export/Import 将Cluster-A中HBase表export到Cluster-B的HDFS中,然后在Cluster-B中使用import导入HBase a) Cluster-A和Cluster-B网络通 Cluster-B中建好相关迁移的表 hbase(main):001:0>create