点击上方“IT那活儿”，关注后了解更多内容，不管IT什么活儿，干就完了！！！
某日接到客户反映hbase的测试环境无法启动故障
。最终定位原因为hbase regions负载过大崩溃，测试人员在恢复失败后对zk实例删除了一个，导致zk实例数据异常最终无法正常启动完成，进一步导致hbase无法恢复启动。
恢复启动后发现hbase的regions数量过多，单节点超过5000 regions，后续对集群进行优化，清理过期历史数据，释放regions至正常水平，最终单节点承载数约1000regions左右。
虽然此次处理的为测试环境，但
处理hbase数据库这种zk+hdfs+hbase常规综合架构问题的思路可以分
享给大家
，于是将此次问题处理的主要流程及思考，结合zookeeper及hbase相关各组件的原理介绍，分享如下。
1.
登录
CM管理界面，发现登录正常，但是集群处于关闭状态。
2.
检查集群节点磁盘状态，发现状态正常，未有磁盘满的节点情况出现。
3.
尝试对
zookeeper服务进行启动，发现无法启动，报错拒接连接。
操作解析：
因
hbase的运行底层是依赖zookeeper组件存储hbase运行所需的关键信息的，比如当前活动master节点、backup-masters节点、table名称信息等，所以我们启动hbase服务之前，前提一定是zookeeper服务启动而且运行正常。
日常处理某些
hbaes异常故障或者性能问题时，如果hbase侧排查未发现明显问题，此时也可以转方向查看hbase所依赖的zookeeper组件或者hdfs组件是否有问题。
4.
检查
zookeeper实例，发现zk的实例被删除了一个，进一步检查zk的数据目录，发现有一个log文件大小为0，怀疑此最新的异常log导致zk无法启动。
5.
对
zk的节点数进行恢复，并将异常的log文件log.d161f9进行删除，同时将次新的一个数据文件和snapshot文件scp到新加入的zk节点数据目录。
操作解析：
zookeeper的运行中会定时将全量数据形成一个快照存放在zookeeper配置的数据目录dataDir中，命名snapshot.<当前事务ID>，全量后续zk中的的变化会存储在一个叫log.<当前事务ID>中。
所以
zookeeper的正常运行其实只需要最近一次的snapshot和log文件，就能保证其数据的完整性，而且所有zk的节点的数据是一致的，如果某个节点数据异常，是可以将leader节点的dataDir中的最新snapshot和log文件复制到异常节点来进行启动恢复的。
6.
再次对处理后的
zookeeper服务进行启动，已能够成功启动服务。
7.
zookeeper启动完成后，使用zkCli.sh命令行进入zk目录，ls查看之前的文件，/hbase所使用的目录均正常，数据未丢失。
8.
恢复
hdfs服务，使用CM界面对hdfs服务进行启动，启动成功。
操作解析：
hbase是一个数据库，数据库的运行会依赖文件系统，hbase所依赖的文件系统即是hdfs，所以启动hbase之前，一定要保证hdfs的服务启动且运行正常的。
同理日常生产中有些hbase的性能问题，我们同样可以从hdfs侧的方向同
步进行排查。
9.
恢复
hbase服务，对hbase服务进行启动，启动成功。
10.
使用
hbase shell命令行进入对hbase服务进行测试，发现异常报错regions not online出现。
11.
检查
hbase-master日志，发现存在大量的reigons online信息。
12.
此时登录
CM界面和hbase-master web界面查看，也发现hbase存在大量的regions还在transition状态，而且超过了水位线。
13.
怀疑
hbase出现regions过载，导致启动后大量的regions需要重新上线，于是等待所有的reigons逐渐上线完成。
操作解
析：
当
hbase运行很久且存在大量数据时，hbase服务虽然启动完成了，但是初始化进行大量的表和reigons上线其实是很耗时的，如果日常维护时发现hbase启动后立即进行表数据的查询发现报错了，千万不要盲目再次进行重启，一定先检查master日志看hbase集群是否还在初始化中，在拥有大量的表和regions的hbase集群中，hbase的完全启动可能需要花费几分钟甚至几十分钟才能完成。
14.
上线完成后，
hbase服务恢复正常，查询已能够正常返回结果，但集群共计10874个regions，共计2个节点，一个节点超过了5000+regions，比正常水平的单节点维持800-1000regions的建议值高了5倍以上。
15.
因
hbase负载严重过载，与业务人员讨论后，确定了清理过期测试数据的方案，释放集群的regions数量，对2021年以前的所有表进行删除。
16.
清理完成后，再次检查
regions总数，集群总regions数量已经2264个了，平均单节点1100个左右，基本处于正常水平。
操作解析：
在官方的建议中，hbase的regionserver节点承载的reigons建议值是低于400，在实际使用和生产环境中，我们认为JVM设置最大32G时，低于1000个reigons是一个正常且安全的值（因为如果按官方低于400部署集群的话，集群所需的机器投入会更多）。
当hbase出现性能问题时
，我们可以首先统计各个regionserver的承载regions数量，过多的regions存在某个reigonserver上时，就容易出现访问热点问题，集群的请求就会不平衡，这是日常最常见的hbase性能问题。
17.
至此，hbase服务无法启动的问题恢复完成，CM界面上所有的服务均启动恢复完毕，故障处理完成。
因为测试集群机器数量无法满足最低3节点原因，部分组件存在黄色告警信息，可忽略。
此次故障初步分析根本原因为hbase集群在进行相关写入测试时，有大量的预分区和数据写入，没有及时进行清理，时间久了导致hbase因负载过高而崩溃。
崩溃后测试人员尝试进行恢复但是失败，期间进行了zk实例的删除，zk异常启动时，写入log失败导致出现了大小为0的最新log文件，进一步导致最终zk无法正常启动。
1. 对hbase历史的数据进行清理，释放集群的regions数量，维持在较健康的水平（已完成）；
2. 测试人员在后续测试后，及时进行hbase表及数据的清理，避免多人大量数据写入导致hbase负载过高而崩溃，清理数据方法为truncate ‘tablename’（已通知测试人员）；
3. 建议测试环境的重要权限进行人员管控，CM管理界面的admin密码不要让过多人员有权进行操作，避免再次出现误删除zookeeper实例或者其他实例的问题。
1. hbase集群的运行通常是一个zk+hdfs+hbase综合的架构，处理hbase问题时，一定不要单只看hbase组件，综合zookeeper和hdfs组件一起分析往往有奇效；
2. zookeeper组件在此综合架构中属于最底层，建议部署时只作为hdfs和hbase组件依赖使用，不要用于其他业务数据的存储使用，避免zk的问题影响到整个hdfs和hbase集群；
3. 文中hbase regionserver建议承载reigons在1000以内是基于JVM设置32G的前提下的，如果环境JVM过小，承载regions的数量建议也对应减少，另regionserver的JVM不建议高于32G，避免GC的时机过久导致服务异常。
IT那活儿
上海新炬中北团队，不管IT什么活儿，干就完了。
636篇原创内容
Official Account
