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. 微信公众号:
扫描关注

你可能感兴趣的:(HBase表Major&Minor Compaction无法结束问题排查)