hbaseput写入数据慢_HBase运维|HBase疑难杂症诊治

hbase2.0处理rit状态记录

问题说明

由于使用HDP3.0&＃xff0c;HDP3.0使用的是hbase2.0.0版本&＃xff0c;hbase的ui页面发现很多表出现了rit&＃xff0c;删除表过程中&＃xff0c;region的状态卡在了opening。先尝试使用hbck2工具进行修复&＃xff0c;发现在hbase2.0的master的rpc方法中没有hbck2中的bypass&＃xff0c;assign方法&＃xff0c;通过源码发现&＃xff0c;hbck2的rpc方法是在hbase2.0.2中才增加的&＃xff0c;所以只能尝试手动处理&＃xff1a;

一.hdfs上已经没有对应目录&＃xff0c;meta里没有对应表状态信息&＃xff0c;存在有对应的分区信息

1. 检查表状态

get &＃39;hbase:meta&＃39;,&＃39;KYLIN_0054K9NLSU&＃39;,&＃39;table:state&＃39;


结果为空

2. 通过源码发现表状态

ENABLED,对应meta表里的值\x80\x00
DISABLED, 对应meta表里的值\x80\x01
DISABLING, 对应meta表里的值\x80\x02
ENABLING, 对应meta表里的值\x80\x03


3. 查找分区信息

scan &＃39;hbase:meta&＃39;,{FILTER &＃61;> org.apache.hadoop.hbase.filter.PrefixFilter.new(org.apache.hadoop.hbase.util.Bytes.toBytes(&＃39;KYLIN_0054K9NLSU&＃39;))}


发现存在有分区记录

put &＃39;hbase:meta&＃39;,&＃39;KYLIN_0054K9NLSU&＃39;,&＃39;table:state&＃39;,&＃39;\x80\x01&＃39;


或者deleteall 表对应的分区信息&＃xff0c;修改后重启hbase&＃xff0c;发现rit状态消失

二.hdfs上已经有对应目录&＃xff0c;meta里有对应表状态信息和分区信息

1. 确认一下表的信息和数据

hbase hbck -summary TableName


2. 检查表状态

get &＃39;hbase:meta&＃39;,&＃39;KYLIN_0354K9NLSU&＃39;,&＃39;table:state&＃39;


meta表里的值\x80\x02&＃xff0c;表的状态为DISABLING

3. 找出异常的region

echo "scan &＃39;hbase:meta&＃39;,{FILTER &＃61;> org.apache.hadoop.hbase.filter.PrefixFilter.new(org.apache.hadoop.hbase.util.Bytes.toBytes(&＃39;KYLIN_0354K9NLSU&＃39;))}"|hbase shell -n|grep OPENING


找出异常的region

4. 将region信息更新为CLOSED状态

put &＃39;hbase:meta&＃39;,&＃39;KYLIN_0354K9NLSU,,1561953520536.30b7d24eaa3209c6e5e8de764ad04855.&＃39;,&＃39;info:state&＃39;,&＃39;CLOSED&＃39;,1562117738678


………

5. 将表状态更新为disable

put &＃39;hbase:meta&＃39;,&＃39;KYLIN_0354K9NLSU&＃39;,&＃39;table:state&＃39;,"\x08\x01",1562120793251


重启hbase后rit消失

存在问题

• rit是删除表的时候出现&＃xff0c;所以表中的数据可以忽略&＃xff0c;上述操作也是表中没有数据时操作

• 如果是生成集群&＃xff0c;已经存在的数据比较多&＃xff0c;不建议直接重启&＃xff0c;可以通过切换master的方式

• 可以使用HDP3.1.1&＃xff0c;里面hbase版本是2.0.2&＃xff0c;可以使用hbck2操作

• 使用hbck2的方法的话&＃xff0c;修改meta状态后还会同步改zookeeper状态&＃xff0c;能避免状态不一致

HBase2.x之RIT问题解决

问题描述

Region-In-Trasition机制&＃xff1a;从字面意思来看&＃xff0c;Region-In-Transition说的是Region变迁机制&＃xff0c;实际上是指在一次特定操作行为中Region状态的变迁&＃xff0c;例如merge、split、assign、unssign等操作。RIT问题指的是在RIT过程中出现异常情况&＃xff0c;然后导致region的状态一直保持在RIT&＃xff0c;使得HBase出现异常。

解决方案

方案一

检查hdfs的健康度&＃xff0c;是否有hbase的文件丢失或损坏&＃xff0c;运行命令hadoop fsck /&＃xff0c;结果如下&＃xff1a;

排除hdfs丢失block的问题。如果出现hdfs的block损坏或丢失的情况&＃xff0c;可以通过hdfs的修复命令进行修复。

方案二

在HBase1.x系列中RIT问题通常可以通过hbase  hbck –repair操作完成修复。但是在HBase2.x系列中&＃xff0c;该命令还没有支持&＃xff0c;所以暂时无法通过这种命令完成修复。结果如下&＃xff1a;

第一次执行发现没有权限&＃xff0c;root用户不是hdfs的超级用户&＃xff0c;安装提示需要以hbase用户去执行该命令。修改如下&＃xff1a;

su hbase -s /bin/sh -c "hbase hbck -repair"


提示为hbase有其他线程正在执行hbck fix命令&＃xff0c;但是其实没有这种命令&＃xff0c;其实从这里就可以看出HBase2.x对于-repair的支持是不够的。我按照提示删除了hdfs(/hbase/.tmp/)上的hbase-hbck.lock文件&＃xff0c;重新运行命令如下&＃xff1a;

方案三

根据RIT状态执行assign或者unassign命令&＃xff0c;状态信息如下&＃xff1a;

经过查询资料&＃xff0c;解决方案如下&＃xff1a;

hbase shell多次执行unassign &＃39;20acfcbd68fd624a78bb34c88f9382d1&＃39;和unassign &＃39;20acfcbd68fd624a78bb34c88f9382d1&＃39; , true都超时结束&＃xff0c;通过修改rpc和zk的超时时间都无法完成(正常超时时间为60000ms&＃xff0c;修改为600000ms)。

方案四

经过多次试验&＃xff0c;最终都无法使得HBase回复正常&＃xff0c;最终决定删除进行测试。

Zookeeper节点删除&＃xff1a;

通过hbase zkcli命令进入Zookeeper命令行界面&＃xff1a;

我想删除节点 /hbase-unsecure/region-in-transition&＃xff0c;但是发现并没有该节点&＃xff0c;经过资料查询了解到HBase2.x的RIT状态并不像HBase1.x系列存储在Zookeeper上。经过测试删除/hbase节点重启hbase并不能解决RIT问题。

HBase表删除&＃xff1a;

hbase shell>disable M_TDY_PT_LCZZ


disable失败&＃xff0c;所以正常删除表操作无法执行。需要进行暴力删除&＃xff0c;暴力删除指的是从元数据进行删除。

先停掉HBase

删除hdfs表目录(记得先备份&＃xff0c;等下恢复用)

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 &＃39;hbase:meta&＃39;,&＃39;rowkey&＃39;, &＃39;column&＃39;


Rowkey信息可以通过hbase的UI看到&＃xff1a;

然后重启HBase&＃xff0c;但是发现问题没有解决。

hbase shell查询数据看到hbase的meta删除失败了&＃xff0c;原本的meta信息还在&＃xff1a;

然后重新删除(delete命令换成deleteall命令)&＃xff1a;

再删除Zookeeper中的/hbase节点&＃xff0c;重启HBase发现RIT问题已经解决了。

后续就是重建表&＃xff0c;然后恢复数据。

Phoenix故障处理笔记

1. Timeline

• 06-26 16:00 Phoenix使用方反馈慢&＃xff1b;

• 06-26 16:02 同事通过监控看到Phoenix HBase集群一个对应的RegionServer&＃xff0c;QueueSize过高&＃xff0c;此bug基本是Butch Put Lock在高并发写入的问题&＃xff0c;我们已在下个版本中增加信息日志定位此问题&＃xff1b;

• 06-26 16:05 同事重启该队列过高的RegionServer&＃xff1b;

• 06-26 16:10 同事跟我说&＃xff0c;好多Phoenix的Region处于RIT状态&＃xff1b;

• 06-26 17:00 暂停该Phoenix集群所有的写入&＃xff1b;

• 06-26 20:00 跟业务沟通&＃xff0c;可能会正常影响一段时间&＃xff0c;经同意。至此各种hbck&＃xff0c;各种重启RegionServer&Master不怎么管用&＃xff0c;RIT数量升至550个&＃xff1b;

• 06-27 12:00 尝试修复&＃xff1b;

• 06-27 15:00 问题修复。

2. 处理流程

2.1 异常现象

1. 大量Region无法上线(NotServingRegionException)

2. Phoenix的SYSTEM.CATALOG系统表也无法上线。

2.2 处理流程

1. 手动assign SYSTEM.CATALOG 表的Region上线&＃xff0c;并且跟踪Master&对应RegionServer的日志。整个offline&open流程都正常。但是中间会由于各种其他的表不在线failover后close掉&＃xff1b;

2. 打印jstack, 感觉这几个线程有问题&＃xff0c;都在waiting&＃xff1b;

   

• 通过上面的信息看&＃xff0c;open region确实有问题。查看Phoenix Indexer Observer源码就会知道是在根据Recover WAL Entry构建索引&＃xff1b;

• 修改hbase.regionserver.executor.openregion.threads数,此配置是负责open region的handler数&＃xff1a;

  
    hbase.regionserver.executor.openregion.threadsname>
    50value>
property>


  默认 3&＃xff0c; 我们这边的hbase版本(1.0.0-cdh5.4.4)

• 重启RegionServer&＃xff1b;

• assign SYSTEM.CATAOG 表的Region&＃xff0c;上线成功&＃xff1b;

• 修修补补&＃xff0c;fixMeta fixAssignments就ok了。

3. 原理分析

1. 重启RegionServer&＃xff0c; 会造成该RegionServer上面的Region下线&＃xff0c;并且被重新Balance到新的RegionServer中。

2. Region在新的RegionServer中open过程会找到该Region下的recover.edits 文件&＃xff0c;进行replay&＃xff1b;

3.Phoenix表使用HBase的协处理类型之Observer&＃xff0c;具体使用查看示例

org.apache.phoenix.hbase.index.Indexer&＃xff0c;此用作根据WAL构建索引的&＃xff0c;具体参考Phoenix的相关材料。

4. 在SYSTEM.CATALOG 的打开过程中&＃xff0c;会查询其他的里面表&＃xff0c;其他的表也处于RIT未恢复。然而其他的表Region在open的过程也需要构建Index&＃xff0c;尚且有一部分在openregion的队列里面。最终SYSTEM.CATALOG无法上线(此处不准确&＃xff0c;纯属囫囵吞枣似的查看源码推测)。

5. 增加open region handler数之后&＃xff0c;重启RegionServer后&＃xff0c;需要进行一些hbck -fixMeta -fixAssginment 将一些未上线的Region上线, 就ok了。

6. 如果出现个别的Region还是上线失败&＃xff0c;那就手动解决吧&＃xff01;个人认为比hbck -repair暴力修复靠谱。