hbase问题总结

个人笔记，总结看到的hbase问题，方便以后查阅

phoenix

Phoenix（凤凰）是一个HBase的开源SQL引擎。你可以使用标准的JDBC API代替HBase客户端API来创建表，插入数据，查询你的HBase数据。

关注compcation耗时

responseTooSlow问题

日志如下:

RpcServer: (responseTooSlow): {"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","starttimems":1650269573591,"responsesize":71,"method":"Scan","param":"scanner_id: 10564518447394377996 number_of_rows: 100 close_scanner: false next_call_seq: 195 

目前推测是因为大量删除了rowkey，导致的compact 频繁导致的。
参考
由ttl引起的responseTooSlow，本例数据量不大，但是有大量的Io。因为设置了ttl导致的定期删除数据。compact时，会处理这些数据。导致io过大，处理缓慢。

调整compact有关的参数如下

   hbase.hstore.compaction.kv.max 10>200

   hbase.hstore.compaction.min 3>6

   hbase.hstore.compactionThreshold 3>6

   hbase.hstore.compaction.max.size 9223372036854775807>5368709120

   hbase.regionserver.thread.compaction.large 5>10

   hbase.hstore.blockingStoreFiles 7>20

   hbase.hregion.max.filesize 10737418240>21474836480

   hbase.master.initializationmonitor.timeout 1200000>3600000

HBase连接Zookeeper的连接超时时间

当gc时间超过连接时间时，HRS异常，会下线

连接时间设置
hbase-site.xml中配置session超时是180s

  <property>
    <name>zookeeper.session.timeout</name>
    <value>180000</value>
  </property>

但是zk的超时时间为40s。原因是

启动日志：INFO [main:QuorumPeer@959] - tickTime set to 2000

/** minimum session timeout in milliseconds */
    public int getMinSessionTimeout() {
        return minSessionTimeout == -1 ? tickTime * 2 : minSessionTimeout;
    }

    /** maximum session timeout in milliseconds */
    public int getMaxSessionTimeout() {
        return maxSessionTimeout == -1 ? tickTime * 20 : maxSessionTimeout;
    }

zk中建立连接会取ServerCnxn中的sessionTimeout，这个值在ZooKeeperServer中做初始化
由于zookeeper服务器tickTime设置的是2000ms，所以maxSessionTimeout默认会被设置为40000ms，所以解决这个问题
需要修改tickTime的值

Premature EOF: no length prefix available

Hbase节点经常挂掉 异常Premature EOF: no length prefix available
http://bcxw.net/article/459.html

NotServingRegionException: Region is not online

集群关机重启后，执行MapReduce任务。报错如下
org.apache.hadoop.hbase.NotServingRegionException: Region is not online

检查region的数据一致性
hbase hbck
结果有10个region INCONSISTENT
数据不一致。
执行hbase hbck -fix修复。需要有hdfs超级用户权限
修复成功状态为OK。可解决该问题。

方法2：因是关机重启后产生的问题。可尝试再次重启。也能解决。
其他方案可参考：http://blog.csdn.net/d6619309/article/details/51509085。

---

RemoteException ：blk块 does not exist

org.apache.hadoop.ipc.RemoteException(java.io.IOException): BP-1760964732-192.168.68.90-1521020908483:blk_1137429208_97966838 does not exist or is not under Constructionblk_1137429208_97967131

总结原因：
gc时间过长
使得zk认为rs已经dead，
zk返回deadregion到master，master就让其他rs负责dead rs下的regions
其他rs会读取wal进行恢复region，处理完的wal，会把wal文件删除
dead rs的gc完成，恢复之后，找不到wal产生报错，
dead rs从zk得知自己dead了，就close了

解决方法：
设置SurvivorRatio=2，增大survivor大小，减少老生带增加速度，减少cms触发几率

设置-XX:CMSInitiatingOccupancyFraction=60，提早cms进行老生带的回收，减少cms的时间

这样避免老生带在回收的时候占满，触发full gc（避免promotion failed和concurrent mode failure）

---

参考
HRegionServer异常下线https://www.cnblogs.com/quchunhui/p/9817792.html

HBase性能调优
https://www.cnblogs.com/likehua/p/4031731.html