hbase2.0处理rit状态记录web
日期shell |
版本号apache |
类别微信 |
描述 |
2019-07-05app |
1.0.0高并发 |
A工具 |
排查hbase2.0的rit问题oop |
问题说明学习
因为使用HDP3.0，HDP3.0使用的是hbase2.0.0版本，hbase的ui页面发现不少表出现了rit，删除表过程当中，region的状态卡在了opening。先尝试使用hbck2工具进行修复，发如今hbase2.0的master的rpc方法中没有hbck2中的bypass，assign方法，经过源码发现，hbck2的rpc方法是在hbase2.0.2中才增长的，因此只能尝试手动处理：
一.hdfs上已经没有对应目录，meta里没有对应表状态信息，存在有对应的分区信息
1. 检查表状态
get 'hbase:meta','KYLIN_0054K9NLSU','table:state'
结果为空
2. 经过源码发现表状态
ENABLED,对应meta表里的值\x80\x00
DISABLED, 对应meta表里的值\x80\x01
DISABLING, 对应meta表里的值\x80\x02
ENABLING, 对应meta表里的值\x80\x03
3. 查找分区信息
scan 'hbase:meta',{FILTER => org.apache.hadoop.hbase.filter.PrefixFilter.new(org.apache.hadoop.hbase.util.Bytes.toBytes('KYLIN_0054K9NLSU'))}
发现存在有分区记录
4. 手动修改表状态或者删除分区信息
put 'hbase:meta','KYLIN_0054K9NLSU','table:state','\x80\x01'
或者deleteall 表对应的分区信息，修改后重启hbase，发现rit状态消失
二.hdfs上已经有对应目录，meta里有对应表状态信息和分区信息
1. 确认一下表的信息和数据
hbase hbck -summary TableName
2. 检查表状态
get 'hbase:meta','KYLIN_0354K9NLSU','table:state'
meta表里的值\x80\x02，表的状态为DISABLING
3. 找出异常的region
echo "scan 'hbase:meta',{FILTER => org.apache.hadoop.hbase.filter.PrefixFilter.new(org.apache.hadoop.hbase.util.Bytes.toBytes('KYLIN_0354K9NLSU'))}"|hbase shell -n|grep OPENING
找出异常的region
4. 将region信息更新为CLOSED状态
put 'hbase:meta','KYLIN_0354K9NLSU,,1561953520536.30b7d24eaa3209c6e5e8de764ad04855.','info:state','CLOSED',1562117738678
………
5. 将表状态更新为disable
put 'hbase:meta','KYLIN_0354K9NLSU','table:state',"\x08\x01",1562120793251
重启hbase后rit消失
存在问题
rit是删除表的时候出现，因此表中的数据能够忽略，上述操做也是表中没有数据时操做
若是是生成集群，已经存在的数据比较多，不建议直接重启，能够经过切换master的方式
可使用HDP3.1.1，里面hbase版本是2.0.2，可使用hbck2操做
使用hbck2的方法的话，修改meta状态后还会同步改zookeeper状态，能避免状态不一致
HBase2.x之RIT问题解决
问题描述
Region-In-Trasition机制：从字面意思来看，Region-In-Transition说的是Region变迁机制，其实是指在一次特定操做行为中Region状态的变迁，例如merge、split、assign、unssign等操做。RIT问题指的是在RIT过程当中出现异常状况，而后致使region的状态一直保持在RIT，使得HBase出现异常。
解决方案
方案一
检查hdfs的健康度，是否有hbase的文件丢失或损坏，运行命令hadoop fsck /，结果以下：
排除hdfs丢失block的问题。若是出现hdfs的block损坏或丢失的状况，能够经过hdfs的修复命令进行修复。
方案二
在HBase1.x系列中RIT问题一般能够经过hbase hbck –repair操做完成修复。可是在HBase2.x系列中，该命令尚未支持，因此暂时没法经过这种命令完成修复。结果以下：
第一次执行发现没有权限，root用户不是hdfs的超级用户，安装提示须要以hbase用户去执行该命令。修改以下：
su hbase -s /bin/sh -c "hbase hbck -repair"
提示为hbase有其余线程正在执行hbck fix命令，可是其实没有这种命令，其实从这里就能够看出HBase2.x对于-repair的支持是不够的。我按照提示删除了hdfs(/hbase/.tmp/)上的hbase-hbck.lock文件，从新运行命令以下：
方案三
根据RIT状态执行assign或者unassign命令，状态信息以下：
通过查询资料，解决方案以下：
hbase shell屡次执行unassign '20acfcbd68fd624a78bb34c88f9382d1'和unassign '20acfcbd68fd624a78bb34c88f9382d1' , true都超时结束，经过修改rpc和zk的超时时间都没法完成(正常超时时间为60000ms，修改成600000ms)。
方案四
通过屡次试验，最终都没法使得HBase回复正常，最终决定删除进行测试。
Zookeeper节点删除：
经过hbase zkcli命令进入Zookeeper命令行界面：
我想删除节点 /hbase-unsecure/region-in-transition，可是发现并无该节点，通过资料查询了解到HBase2.x的RIT状态并不像HBase1.x系列存储在Zookeeper上。通过测试删除/hbase节点重启hbase并不能解决RIT问题。
HBase表删除：
hbase shell>disable M_TDY_PT_LCZZ
disable失败，因此正常删除表操做没法执行。须要进行暴力删除，暴力删除指的是从元数据进行删除。
先停掉HBase
删除hdfs表目录(记得先备份，等下恢复用)
hdfs dfs -cp /hbase/data/hospital/P_TDY_DASC_DE02_01_039_63 /
hdfs dfs -cp /hbase/data/hospital/M_TDY_PT_LCZZ /
hdfs dfs -rm -r -skipTrash /hbase/data/hospital/P_TDY_DASC_DE02_01_039_63
hdfs dfs -rm -r -skipTrash /hbase/data/hospital/ M_TDY_PT_LCZZ
delete 'hbase:meta','rowkey', 'column'
Rowkey信息能够经过hbase的UI看到：
而后重启HBase，可是发现问题没有解决。
hbase shell查询数据看到hbase的meta删除失败了，本来的meta信息还在：
而后从新删除(delete命令换成deleteall命令)：
再删除Zookeeper中的/hbase节点，重启HBase发现RIT问题已经解决了。
后续就是重建表，而后恢复数据。
Phoenix故障处理笔记
1. Timeline
06-26 16:00 Phoenix使用方反馈慢；
06-26 16:02 同事经过监控看到Phoenix HBase集群一个对应的RegionServer，QueueSize太高，此bug基本是Butch Put Lock在高并发写入的问题，咱们已在下个版本中增长信息日志定位此问题；
06-26 16:05 同事重启该队列太高的RegionServer；
06-26 16:10 同事跟我说，好多Phoenix的Region处于RIT状态；
06-26 17:00 暂停该Phoenix集群全部的写入；
06-26 20:00 跟业务沟通，可能会正常影响一段时间，经赞成。至此各类hbck，各类重启RegionServer&Master不怎么管用，RIT数量升至550个；
06-27 12:00 尝试修复；
06-27 15:00 问题修复。
2. 处理流程
2.1 异常现象
1. 大量Region没法上线(NotServingRegionException)
2. Phoenix的SYSTEM.CATALOG系统表也没法上线。
2.2 处理流程
手动assign SYSTEM.CATALOG 表的Region上线，而且跟踪Master&对应RegionServer的日志。整个offline&open流程都正常。可是中间会因为各类其余的表不在线failover后close掉；
打印jstack, 感受这几个线程有问题，都在waiting；
经过上面的信息看，open region确实有问题。查看Phoenix Indexer Observer源码就会知道是在根据Recover WAL Entry构建索引；
修改hbase.regionserver.executor.openregion.threads数,此配置是负责open region的handler数：
<property>
<name>hbase.regionserver.executor.openregion.threads</name>
<value>50</value>
</property>默认 3， 咱们这边的hbase版本(1.0.0-cdh5.4.4)
重启RegionServer；
assign SYSTEM.CATAOG 表的Region，上线成功；
修修补补，fixMeta fixAssignments就ok了。
3. 原理分析
1. 重启RegionServer， 会形成该RegionServer上面的Region下线，而且被从新Balance到新的RegionServer中。
2. Region在新的RegionServer中open过程会找到该Region下的recover.edits 文件，进行replay；
3.Phoenix表使用HBase的协处理类型之Observer，具体使用查看示例
org.apache.phoenix.hbase.index.Indexer，此用做根据WAL构建索引的，具体参考Phoenix的相关材料。
4. 在SYSTEM.CATALOG 的打开过程当中，会查询其余的里面表，其余的表也处于RIT未恢复。然而其余的表Region在open的过程也须要构建Index，尚且有一部分在openregion的队列里面。最终SYSTEM.CATALOG没法上线(此处不准确，纯属囫囵吞枣似的查看源码推测)。
5. 增长open region handler数以后，重启RegionServer后，须要进行一些hbck -fixMeta -fixAssginment 将一些未上线的Region上线, 就ok了。
6. 若是出现个别的Region仍是上线失败，那就手动解决吧！我的认为比hbck -repair暴力修复靠谱。
你们工做学习遇到HBase技术问题，把问题发布到HBase技术社区论坛http://hbase.group，欢迎你们论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup)，很是欢迎你们积极投稿。
本群为HBase+Spark技术交流讨论，整合最优质的专家资源和技术资料会按期开展线下技术沙龙，专家技术直播，专家答疑活动
点击连接钉钉入群：
https://dwz.cn/Fvqv066s或扫码进群
本群为Cassandra技术交流讨论，整合最优质的专家资源和技术资料会按期开展线下技术沙龙，专家技术直播，专家答疑活动
Cassandra 社区钉钉大群：
https://c.tb.cn/F3.ZRTY0o
Cassandra 技术社区微信公众号：
本文分享自微信公众号 - ApacheHudi（ApacheHudi）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。