HBase表Major&Minor Compaction无法结束问题排查

问题起源

 这个问题的起因归咎于最近Y集群上的一张表A在对外提供数据服务的时候突然时不时大量抛超时异常,当时重启Region Server暂时停止抛超时异常,但是问题没有根本解决因为此种情况依旧继续不断复现。

 首先对X集群上的HBase表A做一次Major Compaction(Y集群的表由X集群上的表每天加工完成之后复制到Y集群上,由于Y集群对外提供查询服务,为保证服务稳定因此修复表的操作都在X集群上进行),然后过了一段时间后,在HBase WebUI上查看这张表的大合并是已结束的,但是这张表有两个Rgion的Locality还是很低,于是怀疑两个Region大合没有真正的成功。

 接着查找两个Region所在的Region Server日志发现能够看到两个Region的start compacting记录但是无法找到region compaction completed记录。在Region Server WebUI上发现两个Region处于Closing状态,具体为disabling compacting and flushes for region并且此种状态持续很久,单独对两个Region做大合并仍旧出现同样现象。过段时间两个region就会处于RIT状态。总而言之,两个Region的Major&Minor Compaction无法结束。

image

尝试解决

  1. assign两个Region(失败,具体现象为很快相关Region又会处于RIT状态)

  2. move这两个Region到新的Region Server(失败,现象同上)

  3. 重启两个Region所在的Region Server(失败,现象同上)

  4. 对这张表做快照,随后clone一张新表出来,对这张表做major_compact(失败,现象同上,另外还遇到disable表不成功的现象,如下图所示通过重启Region Server解决)


    image
  5. 写程序,将这张表的数据读出来,写进一张新表上(失败,在读到问题Region 的数据时,会报超时异常,修改超时时间为1h,依然报超时)

  6. drop掉这张表,重新建表,重新加工了一遍存量(成功)

定位原因

 这张表的Data Block Encoding为prefix tree。如果是这种编码方式就会存在Compaction无法结束的风险。

解决办法

 将表drop掉,这个时候hbck一下已经被drop掉的表,可能会发现那两个region还会存在异常,然后重启下这两个region 对应的region server。随后将这张表重新加工一份,就可以了。

  1. disable ‘A’;
  2. drop ‘A’;
  3. hbase hbck -details 'A' 这时候会发现还能够检测出来A表的不一致。我们这里的猜测是,关于A表的region 信息还会存在在Region Server的内存里,并没有随着drop操作而删除干净;
  4. 重启问题Region 所在的Region Server;
  5. hbase hbck -details 'A' 这个时候检测的结果,这张表才是显示正常的,证明此刻这张表删除干净;
  6. 重新建表,指定data block encoding = 'NONE',并重新跑程序进行数据重新加工;
  7. hbase hbck -details 'A' 这个时候结果显示才是没问题,至此问题搞定。

排查总结

 drop掉之后,如果不重启Region Server可能会存在drop表不干净的问题,两个Region的信息驻留在Region Server对应的内存里面,此时如果重新加工一个同样名字的表那这张新表可能存在此类问题,比如online的时候创建快照建不成功或者offline的时候虽然快照可以创建成功,但是极有可能会把未删干净的Region信息给带到snapshot里。另外就是关于跨集群复制,如果在源端集群表的个别region 有问题,在数据通过快照的方式复制到目标集群后,目标端对应的个别region 也会出现一模一样的问题。其实我们公司内部的hbase表从X集群复制到Y集群是通过快照的方式进行:

  1. X集群上的表A进行数据加工
  2. X集群上对表A,建快照:snapshot ‘A’ ‘snapshotA’
  3. Y集群上将A集群的快照复制过来:hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot ***
  4. Y集群disable 'A'
  5. Y集群restore ‘snapshotA’
  6. Y集群enable ‘A’

 通过以上方式把加工出来的表跨集群复制到另外一个集群供应用系统查询从而做到读写分离,但是由于在Y集群存在对表的disable操作,因此该表对于应用而言会存在短暂不可用的现象。目前针对于读写分离场景怎样避免这个短暂不可用还一直未找到非常好的解决方案,如果大家有好的建议或者方案发布到HBase技术社区论坛http://hbase.group




更多技术交流,可关注微信交流群,微信公众号等:

或参考文章: HBase中文社区官网、交流群
1. 微信群

扫描添加小编微信好友(或搜索微信号: Mr_wanyue 添加),回复: HBase 加群

2. 钉钉群:

扫一扫添加

3. 微信公众号:
扫描关注

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,242评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,769评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,484评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,133评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,007评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,080评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,496评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,190评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,464评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,549评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,330评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,205评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,567评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,889评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,160评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,475评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,650评论 2 335

推荐阅读更多精彩内容