Home  >  Article  >  Database  >  记录碰到的HBase问题

记录碰到的HBase问题

WBOY
WBOYOriginal
2016-06-07 16:26:291082browse

目前NoSQL产品最被人诟病的就是其稳定性,不得不承认,目前HBase离做到数据库那样的高稳定还有距离(丢数据、不能读写、DDL失败等严重问题),这篇blog将用来记录我们在运维HBase时碰到的问题(会不断更新),希望能给使用HBase的同学有一些帮助。 1、单台re

目前NoSQL产品最被人诟病的就是其稳定性,不得不承认,目前HBase离做到数据库那样的高稳定还有距离(丢数据、不能读写、DDL失败等严重问题),这篇blog将用来记录我们在运维HBase时碰到的问题(会不断更新),希望能给使用HBase的同学有一些帮助。

1、单台regionserver的region数很多后写速度疯狂下降
具体请见:http://koven2049.iteye.com/blog/1144526

2、region server OOM
碰到过两种造成region server OOM的状况:
* rowKey设计的问题,写的一直是同一行,version配置的又比较大,无法split,从而导致compact时候需要压缩一个巨大的文件;
* 应用方create table时,通过setMaxFileSize设置了一个3G的值,导致compact时需要消耗6G的空间,从而OOM。
造成这两次OOM的原因都是由于compact,因此需要修改compact,避免OOM,官方在0.92里做了一定的处理,具体可见:HBASE-3290。

3、master OOM
当系统中有很多region时,很容易就造成master OOM了,具体请见:HBASE-3906,HBase 0.90.4或以后版本的同学可忽略此问题。

4、.meta.表hole
hbck时,出现了Chain of regions in table … is broken; edges does not contain …,造成这个的原因是某张表的regions的startKey和endKey没有形成闭环,这会导致某些数据无法读写,出现这个问题时,最大的麻烦是不能随意去进行修复,因为有可能会导致丢数据。
我们之前碰到这个问题的原因是split的时候offlineParentInMeta超时了,具体描述大家请见:http://koven2049.iteye.com/blog/1199519,这个bug我们已修复并提交给官方,为HBASE-4562,使用HBASE 0.90.5或以后版本的同学可忽略此bug。
但我们并不确定修复了这个bug就能避免.meta.表不出现hole现象,因此后面会考虑做个工具来安全的修复这个问题。

5、.meta.表中出现重复的startKey/endKey
hbck时,出现了Chain of regions in table …contains less elements than are listed in META; visited=,出现此情况非常严重,此时客户端读写会出现混乱或挂起的现象,可能会导致丢数据,而且很难恢复。
我们出现这个现象的原因是官方的这个bug造成的,这个bug已经修复,具体请见HBASE-3946,使用HBASE 0.90.4或以后版本的同学可忽略此bug。
但我们并不确定修复了这个bug就能避免.meta.表不出现重复的startKey/endKey,因此后面会考虑做个工具来安全的修复这个问题。

6、master进行split hlog时有可能造成数据丢失
具体请见:http://koven2049.iteye.com/blog/1199669,目前官方未修复此bug,请使用HBase的同学自行评估进行修复。

7、在读取大数据时造成写的速度也下降
这个的原因在于HBase的单连接通信效率低的问题,目前官方未有此方面的修复方法,暂时来看只能是要么将读写分开,要么折腾成多个连接。

8、disable表失败
现象为disable表时导致master挂掉,无法disable。
造成master挂掉的原因为表中有region处于没有serverAddress的现象,而表此时又处于disabling的状态,导致无法enable,修复的方法可以是先从zk节点的table下删除此表,然后再去disable,通常是可以的。
官方相关的两个patch请见:HBASE-3892和HBASE-4064。

9、.meta.表和root表被重复分配到两台region server
具体请见:http://koven2049.iteye.com/blog/1199667。

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn