运维日记丨Hbase disable table卡住问题解决方案

新运维新数据 2022-12-10

3571

各位新朋友～记得先点蓝字关注我哦～

今天小编在habse中清除某张表数据时，提示报错

hbase(main):016:0> truncate_preserve 'bigtable1000w'
Truncating 'bigtable10wclone' table (it may take a while):
Disabling table...


ERROR: Table bigtable1000w is disabled!


For usage try 'help "truncate_preserve"'


Took 1.8570 seconds

于是查看该表的状态

hbase(main):001:0> is_disabled 'bigtable1000w'
false                                                                                                                                                                                                                                     
Took 0.8607 seconds                                                                                                                                                                                                                       
=> 1
hbase(main):002:0> is_enabled 'bigtable1000w'
false

从上面可以看到一个很奇怪的现象，这张表既不是disable状态也不是enable状态

接着继续去查看元数据表中记录的状态

hbase(main):003:0> get 'hbase:meta','bigtable1000w','table:state'
COLUMN                                                      CELL                                                                                                                                                                          
 table:state                                                timestamp=1647402770319, value=\x08\x02                                                                                                                                       
1 row(s)

可以看到他的值是\x08\x02 ，但是正常的值是\x08\x00(Enabled)或者\x08\x01(Disabled)

从网页中查看该表，显示该表正在disabling。

我们从list_locks中可以看到确实是锁

hbase(main):004:0* list_locks     


TABLE(bigtable1000w)                                                                                                                                                                                                                      
Lock type: SHARED, count: 2                                                                                                                                                                                                                                                                                                                                                                                                                       


REGION(7a4e76f44324b68ca4b3fbf2b776b46f)                                                                                                                                                                                                  
Lock type: EXCLUSIVE, procedure: {"className"=>"org.apache.hadoop.hbase.master.assignment.UnassignProcedure", "parentId"=>"868", "procId"=>"869", "submittedTime"=>"1647402770402", "owner"=>"hbase", "state"=>"WAITING_TIMEOUT", "stackId"=>[5, 7, 8, 10, 12, 15, 17, 19, 21, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 51, 53, 55, 57, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 82, 84, 86, 88, 90, 92, 94, 96, 98, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, 128, 130, 132, 134, 136, 138, 140, 142, 144, 146, 148, 150, 152, 154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182, 184, 186, 188, 190, 192, 194, 196, 198, 200, 202, 204, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 228, 230, 232, 234, 236, 238, 240, 242, 244, 246, 248, 250, 252, 254, 256, 258, 260, 262, 264, 266, 268, 270, 272, 274, 276, 278, 280, 282, 284, 286, 288, 290, 292, 294, 296], "lastUpdate"=>"1647485472955", "timeout"=>600000, "stateMessage"=>[{"transitionState"=>"REGION_TRANSITION_DISPATCH", "regionInfo"=>{"regionId"=>"1647248063686", "tableName"=>{"namespace"=>"ZGVmYXVsdA==", "qualifier"=>"YmlndGFibGUxMDAwdw=="}, "startKey"=>"", "endKey"=>"NTAxNjQ2MTIzMDMw", "offline"=>false, "split"=>false, "replicaId"=>0}, "hostingServer"=>{"hostName"=>"cdh01", "port"=>16020, "startCode"=>"1647397806214"}, "attempt"=>147}], "locked"=>true}

小编于是就去查找为什么会出现这种现象。

于是看到了一个明显的错误，该表的一个region存在RIT（Regions in Transition）

RIT真的是一个恐怖的存在。下一次文章我们讲一下RIT。

Region-In-Transition说的是Region变迁机制，实际上是指在一次特定操作行为中Region状态的变迁。

解决RIT问题

当存在RIT时需要先解决RIT问题。

我们需要利用bypass将卡住的procedure进行释放。

可以看到EXCLUSIVE的lock只有region级别的，图中红框圈出来的就是占有这个锁的procedure id以及它的parent procedure id, 由此我们知道如果想要重新assign/unassign这个region,那么一定要bypass这个procedure。

[root@cdh03 hbase-hbck2]#  hbase hbck -j hbase-hbck2-1.2.0.jar bypass/assigns/unassign [region]

解决disabling问题

当根据上述方法成功解决RIT问题后，可以由以下两种方式解决disable的问题。

方案一：碰大运

重新对表进行操作

hbase(main):007:0> truncate_preserve ' bigtable1000w '
Truncating 'test2' table (it may take a while):
Disabling table...
Truncating table...

若成功则皆大欢喜，若不成功则继续按照以下方法继续。

方案二：修改表元数据

我们从上述中已经看到该表的状态值既不是\x08\x00(Enabled)也不是\x08\x01(Disabled)

修改该值

hbase(main):007:0* put 'hbase:meta','bigtable1000w','table:state',value='\b\0'
Took 0.0865 seconds

查看，一般情况下他会被修改成上述两个值中的一个，但是小编出现了一个奇怪的值，无法正常解决。

hbase(main):008:0> get 'hbase:meta','bigtable1000w','table:state'
COLUMN                                                      CELL                                                                                                                                                                          
 table:state                                                timestamp=1647423839330, value=\x5Cb\x5C0

TIPS:建议不要轻易去修改元数据中的内容，若修改元数据表出错对生产库影响极大。

方案三：利用hbck2修复

HBCK2 是 Apache HBase 集群的修复工具。

Operator 中的问题都属于 bug。之所以需要 HBCK2 修复，意味着是一种在新的 hbase 版本中发布之前进行修复错误的解决方法。

HBCK2 是用来修复的，对于集群运行中的 inconsistencies 或堵塞问题，可以查看集群 Master 运行的日志或者 Web UI。一旦发现问题，可以使用 HBCK2 工具来要求 Master 执行修复或跳过坏状态。

去GitHub或者hbase官网上下载该工具并使用（不做说明）

我们将该表的状态修改为disable

[root@cdh03 hbase-hbck2]# hbase hbck -j hbase-hbck2-1.2.0.jar setTableState 'bigtable1000w' DISABLED

查看状态是否正常

hbase(main):029:0* is_disabled 'bigtable1000w'
true                                                                                                                                                                                      
Took 0.0465 seconds                                                                                                                                                                       
=> 1


hbase(main):030:0> get 'hbase:meta','bigtable1000w','table:state'
COLUMN                                          CELL                                                                                                                                      
 table:state                                    timestamp=1647425277262, value=\x08\x01                                                                                                   
1 row(s)
Took 0.0266 seconds

我们最后再接着清除数据

hbase(main):007:0> truncate_preserve ' bigtable1000w '
Truncating 'test2' table (it may take a while):
Disabling table...
Truncating table...

总体思路解决

1、其实HBase-2.x版本的运维思路很简单，因为使用了procedure，集群出现meta跟regionserver不一致的状态是很少的，一般都是有procedure出问题了。那么我们主要就是看怎么解决这个有问题的procedure。

2、如果是table/namespace级别的修改，因为涉及到很多region的锁，如果需要bypass的话需要找到root procedure然后使用bypass -or.

3、如果只是region级别的问题，则bypass -o即可。

4、bypass之后检查locks的页面，看看是不是锁都释放了，如果没有锁了则根据需求进行assign或者unassign,或者对table的属性进行还原。

美创是国内领先的数据库服务提供商。服务团队拥有PG ACED 1名、Oracle&PG ACE 3人、DSI智库专家5名、DSMM测评师7名、OCM 20余人、数十名Oracle OCP、MySQL OCP、TDSQL TCP、OceanBase OBCP、TiDB PTCP、达梦 DCP、人大金仓、红帽RHCA、中间件weblogic、tuxedo、CISP-DSG、CISSP、CDGA、CDPSE、CZTP、CDSP等认证人员，著有《DBA攻坚指南：左手Oracle，右手MySQL》，《Oracle数据库性能优化方法和最佳实践》，《Oracle内核技术揭秘》，《Oracle DBA实战攻略》等多本数据库书籍。运维各类数据库合计5000余套，精通Oracle、MySQL、SQLServer、DB2、PostgreSQL、MongoDB、Redis、TDSQL、OceanBase、达梦、人大金仓等主流商业和开源数据库。美创拥有完善的运维体系和人员培养体系，并同时提供超融合、私有云整体服务解决方案、数据安全咨询及运营服务方案等，已为金融、政府、企业、能源等多个行业的客户提供量身定制的各类服务，赢得了客户的高度赞誉和广泛认可。

hbase table

文章转载自新运维新数据，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

运维日记丨Hbase disable table卡住问题解决方案

评论