导语：
近期腾讯云某家大客户的hbase master一直无法启动，经过仔细诊断之后发现是由于hbase的WAL文件非常多（达到15TB），导致hbase在zk的节点（存储WAL文件信息的节点）超过4096*1024 默认大小，无法正常提供服务。因此，hbase master无法正常启动。通过增加zk节点的大小参数，并且优化WAL文件，最终解决该问题。
一、故障现象
hbase master启动不了，日志报错无法连接上zk 的 /hbase/splitWAL节点：
图1： hbase master 报错日志既然是报错连接不上zk的节点 /hbase-unsecure/splitWAL（这个节点存储的是hbase的WAL文件信息），那么我们登录上zk去测试该节点：
图2： zk的报错信息从zk的报错信息可以看到， /hbase-unsecure/splitWAL 节点的大小“ Packet len10980003 is out of range”，也就是节点大小超出范围。
二、故障分析与解决
从上述报错来看，导致hbase master无法启动的原因是hbase在zk的节点（存储WAL文件信息的节点）超过
一定值，导致hbase master无法连接到zk节点，进而无法启动。按理说，hbase存储WAL不会太多，zk节点也不会超过4M大小。我们先查看hbase 的 WAL文件大小：
图3： hbase 的 WAL文件大小hbase 的 WAL文件大小超过15TB，看来确实是异常
我们进一步诊断查看zk的源代码：
代码语言：java复制protected final ByteBuffer lenBuffer = ByteBuffer.allocateDirect(4);
protected ByteBuffer incomingBuffer = lenBuffer;
protected void readLength() throws IOException {
int len = incomingBuffer.getInt();
if (len < 0 || len >= ClientCnxn.packetLen) {
throw new IOException("Packet len" len " is out of range!");
}
incomingBuffer = ByteBuffer.allocate(len);
}
public static final int packetLen = Integer.getInteger("jute.maxbuffer", 4096 * 1024);发现zk的单节点大小不能超过 4096*1024，10980003 已经超过该阈值。
经过上诉分析，基本上可以判断是由于hbase 的WAL文件太多，导致zk节点 /hbase-unsecure/splitWAL 接近10M，超过4M的阈值限制，导致hbase master无法连接到 zk节点 /hbase-unsecure/splitWAL，进而无法启动hbase master。
三、故障解决办法
最简单的解决办法，就是修改hbase连接zk的节点参数大小，使得其超过10M，这样可以将hbase master启动；然后再处理WAL过大问题，一般而言，15TB的WAL文件意味着hbase 的WAL机制已经异常，需要手工处理。
通过修改hbase-env.sh 文件，将参数 -Djute.maxbuffer = 20971520 (20M) 设置到 HBASE_OPTS。具体设置方法根据大数据平台不同而有差异。比如，如果是ambari搭建的大数据集群，那么直接在ambari界面修改hbase的配置文件，在hbase-env.sh文件最后添加以下一行参数：
代码语言：javascript复制export HBASE_OPTS = "$HBASE_OPTS -Djute.maxbuffer = 20971520"如果是自己手工搭建的，直接在修改hbase-env.sh 文件，将上述一行参数添加到hbase-env.sh 文件末尾。
最后重启hbase，即可生效。
四、后续进一步优化
进一步的还需要找到hbase 为什么有如此多WAL文件的原因，找出根源才能彻底解决这个问题。首先需要手工处理这15TB的WAL文件，然后再找出hbase 产生如此多WAL文件的根本原因，进行彻底解决。
