【问题1】HBase Shell:ERROR: org.apache.hadoop.hbase.IPc.ServerNotRunningYetException: Server is not running yet
原因：hadoop处于safe mode
hadoop dfsadmin -safemode get 查看hadoop当前启动状态是否为safe mode
hadoop dfsadmin -safemode leave 退出
【问题2】Rowkey设计问题
现象
打开HBase的Web端，发现HBase下面各个RegionServer的请求数量非常不均匀，第一个想到的就是HBase的热点问题，上面是HBase下某张表的region请求分布情况，从中我们明显可以看到，部分region的请求数量为0，而部分的请求数量可以上百万，这是一个典型的热点问题。
原因
HBase出现热点问题的主要原因无非就是rowkey设计的合理性，像上面这种问题，如果rowkey设计得不好，很容易出现，比如：用时间戳生成rowkey，由于时间戳在一段时间内都是连续的，导致在不同的时间段，访问都集中在几个RegionServer上，从而造成热点问题。
解决
知道了问题的原因，对症下药即可，联系应用修改rowkey规则，使rowkey数据随机均匀分布
建议
对于HBase来说，rowkey的范围划定了RegionServer，每一段rowkey区间对应一个RegionServer，我们要保证每段时间内的rowkey访问都是均匀的，所以我们在设计的时候，尽量要以hash或者md5等开头来组织rowkey
【问题3】Region重分布
现象
HBase的集群是在不断扩展的，分布式系统的最大好处除了性能外，不停服横向扩展也是其中之一，扩展过程中有一个问题：每次扩展的机器的配置是不一样的，一般，后面新加入的机器性能会比老的机器好，但是后面加入的机器经常被分配很少的region，这样就造成了资源分布不均匀，随之而来的就是性能上的损失
每台RegionServer上的请求极为不均匀，多的好几千，少的只有几十
原因
资源分配不均匀，造成部分机器压力较大，部分机器负载较低，并且部分Region过大过热，导致请求相对较集中。
解决
迁移部分老的RegionServer上的region到新加入的机器上，使每个RegionServer的负载均匀。通过split切分部分较大region，均匀分布热点region到各个RegionServer上。
对比前后两张截图我们可以看到，Region总数量从1336增加到了1426，而增加的这90个region就是通过split切分大的region得到的。而对region重新分布后，整个HBase的性能有了大幅度提高。
建议
Region迁移的时候不能简单开启自动balance，因为balance主要的问题是不会根据表来进行balance，HBase的自动balance只会根据每个RegionServer上的Region数量来进行balance，所以自动balance可能会造成同张表的region会被集中迁移到同一个台RegionServer上，这样就达不到分布式的效果。
基本上，新增RegionServer后的region调整，可以手工进行，尽量使表的Region都平均分配到各个RegionServer上，另外一点，新增的RegionServer机器，配置最好与前面的一致，否则资源无法更好利用。
对于过大，过热的region，可以通过切分的方法生成多个小region后均匀分布(注意：region切分会触发major compact操作，会带来较大的I/O请求，请务必在业务低峰期进行)
【问题4】JVM参数调整
GC问题导致HBase整个系统的请求下降，通过适当调整JVM参数的方式，解决HBase RegionServer的GC问题。
export HBASE_REGIONSERVER_OPT="-Xmx8g -Xms8g -Xmn128m -XX:+UseParNewGC -XX:UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+printGCDetails -XX:+PrintGCTimeStamps -Xloggc:${HBASE_HOME}/logs/gc-${hostname}-hbase.log
建议
对于HBase来说，本身不存在单点故障，即使宕掉1,2台RegionServer，也只是使剩下几台的压力有所增加，不会导致整个集群服务能力下降很多。但是，如果其中某台RegionServer出现Full GC问题，那么这台机器上所有的访问都会被挂起，客户端请求一般都是batch发送的，rowkey的随机分布导致部分请求会落到该台RegionServer上，这样该客户端的请求就会被阻塞，导致客户端无法正常写数据到HBase。所以，对于HBase来说，宕机并不可怕，但长时间的Full GC是比较致命的，配置JVM参数的时候，尽量要考虑避免Full GC的出现。
【问题5】堆内存溢出的问题
java.lang.OutOfMemoryError
从错误本身可以发现是堆错误，很明显是设置的值太小而导致这样错误。
在hadoop开始配置的时候，在hadoop/etc/hadoop/目录下的hadoop-env.sh文件中
export HADOOP_HEAPSIZE=
是被注释掉的，查看上面的注释，这个值默认为1000，单位为Mb
这里去掉注释，修改为4000，需要注意的是这里要根据内存大小来选择值
export HADOOP_HEAPSIZE=4000
export HBASE_HEAPSIZE=1024
【问题6】drop表
drop 表后，会现 hadoop.hbase.catalog.MetaReader - No serialized HRegionInfo in keyvalues的警告，通过命令修复：
hbase hbck -fixEmptyMetaCells
【问题7】Region Server 意外退出
1.1 背景
报错信息如下：
ERROR org.apache.hadoop.hbase.regionserver.HRegionServer: ZooKeeper session expired
之后， regionserver就退出了。
对于一个 reigonserver， 它需要将自己注册到 Zookeeper 上 master 的 Znode 上。这样的目的，是当master 宕机或者新的master启动的时候，能及时收到通知。对于 regionserver来说，维持和 Zookeeper 的联系是非常重要的。因为 regionserver 需要定期的将心跳包发给 master server。如果 regionserver 不能及时的知道 master 的改变，就会导致 regionserver 和 master 失去联系，而成为一个僵死的进程。
于是，在默认情况下，regionserver 遇到这种情况，就选择退出。
1.2 原因
为什么 regionserver 和Zookeeper的session expired? 可能的原因有
网络不好
Java full GC， 这会 block 所有的线程。如果时间比较长，也会导致 session expired
1.3 解决办法
将 Zookeeper 的 timeout 时间加长
<property>
<name>zookeeper.session.timeout</name>
<value>120000</value>
</property>
配置“hbase.regionserver.restart.on.zk.expire” 为true
这样子，遇到 ZooKeeper session expired ， regionserver 将选择 restart 而不是 abort
为了避免 java full GC suspend thread 对Zookeeper heartbeat 的影响，我们还需要对 hbase-env.sh进行配置。
将
export HBASE_OPTS="$HBASE_OPTS -XX:+HeapDumpOnOutOfMemoryError \
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode"
修改成
export HBASE_OPTS="$HBASE_OPTS -XX:+HeapDumpOnOutOfMemoryError
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
-XX:+UseCMSInitiatingOccupancyOnly -XX:+UseParNewGC -Xmn256m"
【问题8】如何提高HBase客户端的读写性能？请举例说明。
①开启bloomfilter过滤器，开启bloomfilter比没开启要快3、4倍
②Hbase对于内存有特别的嗜好，在硬件允许的情况下配足够多的内存给它
③通过修改hbase-env.sh中的
export HBASE_HEAPSIZE=3000 #这里默认为1000m
④增大RPC数量
通过修改hbase-site.xml中的
hbase.regionserver.handler.count属性，可以适当的放大。默认值为10有点小
【问题9】断电后regionserver丢失
故障原因
可能是虚拟主机突然断电，hbase的所有节点都在这个虚拟机上，因此全部停机。启动起来后，发现很多region丢失：is not online。
检测HDFS文件是否损坏
使用hadoop命令: hadoop fsck / , 可以看到/ 目录下fs是否是Healthy。
查看-ROOT-、.META.表的状态
通过可视化界面查看-ROOT-、.META.表的状态是否正常。
http://hmaster:60010/master-status
看到只有-ROOT-表，而没有了.META.表，说明meta表损坏，而数据并未丢失。
通过scan ‘.META.’ 确定META表在Region Server2上，而Region Server 2在hbase启动后，过一段时间后，IPC端口就不通了，master无法与region server通讯，无法stop，也无法执行修复命令。
所以需要在hbase服务启动后，在正常状态时，迅速执行修复命令。
zookeeper上存储hbase 基本信息，可以删除后，重新启动，会重新自动创建。
[hbase@hmaster hb]$ hbase-0.94.27/bin/hbase zkcli
[zk: hslave1,hmaster,hslave2:2181(CONNECTED) 1] ls /hbase
[splitlog, online-snapshot, unassigned, root-region-server, table92, backup-masters, rs, table, draining, master, shutdown, hbaseid]
通过查看region信息，发现很多表的region都缺失了。
使用修复meta命令，发现问题依然存在，然后尝试修复assignments，ok。
[hbase@hmaster hb]$ hbase-0.94.27/bin/hbase hbck -fixAssignments
- 再次确认所有的用户表
通过可视化界面，可以看到所有的表的region信息，之前由于有些表的region信息丢失导致异常，通过http://hmaster:60010/master-status确认所有的表的regions全部恢复。
- hbase hbck 修复命令
问题分析的主要手段
1、监控系统：首先用于判断系统各项指标是否正常，明确系统目前状况
2、服务端日志：查看例如region移动轨迹，发生了什么动作，服务端接受处理了哪些客户端请求。
3、gc日志：gc情况是否正常
4、操作系统日志和命令：操作系统层面、硬件是否故障，当前状况如何
5、btrace：实时跟踪目前服务端的请求和处理情况
6、运维工具：通过内置于系统中的功能，查看服务器实时处理状况
其实以上手段，大部分系统都具备，不过各有各的用法，下面我会通过常见的问题来梳理这6大手段。
常见问题1：个别请求为什么很慢？
个别请求慢是用户遇到最多的问题，首先需要明确是客户端还是服务端原因，进而分析服务端状况以及捕获这些请求来明确定位。
1、通过客户端日志来初步分析下慢请求的规律，尝试在客户端确定请求的rowkey和操作类型。
2、确定是不是一段时间内集中出现慢请求，如果是那么可以参考常见问题2来解决。
3、查看服务端监控，观察响应时间是否平稳，maxResponseTime是否出现峰值。如果存在，那么可以初步确定是服务端问题。
4、客户端分析无效，可以通过运维工具在服务端捕获慢请求的rowkey和操作类型。
5、确定rowkey对应的region，初步查看是否存在数据表参数配置不合理（例如version设置过多、blockcache、bloomfilter类型不正确）、storefile过多、命中率过低等问题。
6、尝试重试这些请求或者直接分析hfile来查看返回结果是否过大，请求是否耗费资源过多。
7、查看服务端关于hdfs的监控和日志，以及datanode日志，来分析是否存在hdfs块读取慢或者磁盘故障。
常见问题2：客户端读写请求为什么大量出错？
读写请求大量出错的现象主要有两类：1、大量出现服务端exception 2、大量超时。其中第一种有异常信息较好判断问题所在。
1、大量服务端exception一般是region不在线导致的，可能是region在split但是时间很长超过预期，或是meta数据错误导致客户端获取region location错误。以上现象均可通过日志来定位。
2、遇到大量超时，首先应该排除服务端是否出现了fullgc或者ygc时间过长。前者可能由于内存碎片、cms gc速度来不及导致，后者一般是由于系统使用了swap内存。
3、通过系统命令和日志来查看是否有机器load过高，磁盘压力过大，磁盘故障。
4、查看监控是否出现callqueue积压，请求无法得到及时处理，进一步通过call查看工具或者jstack可以查看正在处理的call和进程堆栈信息。
5、通过datanode日志和hbase访问dfs的时间，来判断问题是否在hdfs层。
6、查看监控判断是否出现blocking update，memstore是否已接近系统设置的上限。
常见问题3：系统为什么越来越慢了？
系统原来挺快的，为什么越来越慢？多数是不合理的服务端配置导致的，可以通过以下几个方面来分析。
1、磁盘读写和系统load是不是比以前高了，初步判断导致系统变慢的原因。
2、如果磁盘读写加剧，重点查看flush是否过小，compact是否过频，尤其是major compact是否有必要，从测试结果来看compact产生的磁盘io对系统性能影响很大。
3、单个region的storefile个数是否有成倍提高
4、命中率是否有下降趋势
5、regionserver是否存在region分配不均衡导致的读写集中，或者读写handler的竞争
6、datablock的本地化率是否出现下降
7、是否存在datanode运行不正常，可以通过监控查看是否有个别机器读取block时间明显偏高
常见问题4：数据为什么没了，明明写进去过？
数据丢失也是HBase的常见bug，分为临时性和永久性两类。临时性的丢失往往是由于hbase本身的正确性问题导致瞬间读取数据错误。永久性丢失一般是日志恢复bug或者region的二次分配。
1、首先可以通过hbck或者master日志排查丢失的数据所在region是否发生过二次分配
2、集群中的regionserver是否出现过abort，日志是否正确恢复。
3、扫描storefile确定目前数据情况
4、扫描logs或者oldlogs中的文件来确定是否写入过这些数据，以及写入数据的时间，配合rs的日志来确定当时server的行为
5、根据写入数据的时间，确定regionserver是否正确完成了flush并且将数据写入磁盘
常见问题5：为什么有服务器进程挂了？
regionserver发生abort的场景很多，除了系统bug引起的以外，线上遇到最多的就是fullgc引起的zk节点超时和文件系统异常。
1、查看regionserver日志查询FATAL异常，确定异常类型
2、查看gc日志确定是否发生fullgc或者ygc时间过长
3、如果没有征兆，日志突然中断，首先需要考虑是否发生了OOM（0.94版本会直接kill -9）。
4、可以通过系统内存监控判断是否出现被占满的情况
5、查看datanode是否出现异常日志，regionserver可能由于roll log或者flush时的文件系统异常导致abort
6、排除人为调用stop的情况
HBase健康体检
一个集群似乎否健康，大体可以从以下几个方面来判断
1、单region的storefile数量是否合理
2、memstore是否得到合理的利用，此项指标与hlog的数量和大小相关
3、compact和flush的流量比值是否合理，如果每天仅flush 1G却要compact几十上百G就是明显的浪费
4、split似乎否过频，能否采取pre-sharding的方式来预分配region
5、集群的region是否过多，zk在默认参数下无法支撑12w以上的region个数，并且region过多也会影响regionserver failover的时间
6、读写相应时间是否合理，datablock的读取延时是否符合预期
7、flush队列、callqueue长度、compact队列是否符合预期。前两者的积压都会造成系统不稳定。
8、failedRequest和maxResponseTime
9、gc状况，过长的ygc和过频的cms都需要警惕
运维工具
HBase官方版本的可运维性的确很差，为了能最大限度的保证线上系统安全，快速定位故障原因，阿里做了很多建设性的工作。
1、建立了完整的监控体系，根据日常测试和线上运行经验，加入了很多监控点。
2、监控的粒度达到region级别
3、call dump和线上慢请求追踪功能
4、btrace脚本体系，出现问题直接运行查看程序内部信息
5、日志收集和报警
6、在线表维护工具和storefile、logs分析工具
