HBase运维中遇到的问题

Mumunu-

已于 2024-01-09 10:41:11 修改

阅读量7k

点赞数

分类专栏： hadoop devops 文章标签： hbase hadoop big data

于 2022-03-14 15:32:01 首次发布

本文链接：https://blog.csdn.net/h952520296/article/details/123479796

版权

devops 同时被 2 个专栏收录

95 篇文章 7 订阅

订阅专栏

hadoop

82 篇文章 5 订阅

订阅专栏

1、PleaseHoldException: Master is initializing

hadoop 3.2.1

hbase 2.2.5

各种配置之后，出现的错误具体为：

进去 hbase shell 之后，出现：

hbase(main):001:0> list_namespace
NAMESPACE
 
ERROR: org.apache.hadoop.hbase.PleaseHoldException: Master is initializing
        at org.apache.hadoop.hbase.master.HMaster.checkInitialized(HMaster.java:2811)
        at org.apache.hadoop.hbase.master.HMaster.getNamespaces(HMaster.java:3107)
        at org.apache.hadoop.hbase.master.MasterRpcServices.listNamespaceDescriptors(MasterRpcServices.java:1261)
        at org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
        at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:418)
        at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
        at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:338)
        at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:318)
 
For usage try 'help "list_namespace"'
 
Took 8.7219 seconds

比较伤脑筋。

其根源在于，有的server没有online

为这个问题搞了好久，包括换版本。但是自己确信早先是工作的啊。

后来彻底的初始化，才好了。其根源在于 ./hdfsdfs -rm-r /hbase 这句话。

因此，纯粹，彻底的初始化步骤：

清除/hbase文件系统，清除zk，然后才会好。

liuzhi@sihan-local:/data/hadoop-3.2.1/bin$ ./hdfs dfs -rm -r /hbase
Deleted /hbase
liuzhi@sihan-local:/data/hadoop-3.2.1/bin$ cd /data/zookeeper/
liuzhi@sihan-local:/data/zookeeper$ ./bin/zkCli.sh
[zk: localhost:2181(CONNECTED) 0] ls /
[admin, brokers, cluster, config, consumers, controller, controller_epoch, hbase, isr_change_notification, latest_producer_id_block, log_dir_event_notification, zookeeper]
[zk: localhost:2181(CONNECTED) 2] deleteall /hbase
Node does not exist: /hbase
[zk: localhost:2181(CONNECTED) 3] ls /
[admin, brokers, cluster, config, consumers, controller, controller_epoch, isr_change_notification, latest_producer_id_block, log_dir_event_notification, zookeeper]
[zk: localhost:2181(CONNECTED) 4] quit

如果有kerberos的话会报错

Authentication is not valid : /hbase/splitWAL

.解决方式

先使用命令查看该节点的权限

getAcl /hbase 返回结果如下图所示

可以看到sasl用户是hbase

编写jaas-zk-keytab.conf文件

Client {
   com.sun.security.auth.module.Krb5LoginModule required
   useKeyTab=true
   keyTab="/root/hbasenew.keytab"
   storeKey=true
   useTicketCache=false
   principal="hbase@RSD.COM";
};

在执行zookeeper-client前将jaas-zk-keytab.conf加载到环境变量

export CLIENT_JVMFLAGS="-Djava.security.auth.login.config=jaas-zk-keytab.conf"

登陆zookeeper

 zookeeper-client -server master:2181

连接客户端时候一定要用-server参数指定zookeeper节点，不然连接不上

删除节点

成功删除。

这样子纯粹做了一遍之后，重启hbase 确实好了

2、Permission denied: user=hbase, access=WRITE, inode="/":hdfs:supergroup:drwxr-xr-x

集成了kerberos的hbse可能会遇到这个问题

hdfs dfs -chown hbase:supergroup  /hbase

修改权限给hbase即可

3、 Call exception, tries=6, retries=16, started=6684 ms ago, cancelled=false, msg=Call to slave4/172.31.255.232:16020 failed on local exception: org.apache.hadoop.hbase.exceptions.ConnectionClosedException: Connection closed, details=row 'kudu_test,10130612953356,99999999999999' on table 'hbase:meta' at region=hbase:meta,,1.1588230740, hostname=slave4.zhendao.com,16020,1658470013588, seqNum=-1

		//what principal the master/region. servers use.
		configuration.set("hbase.regionserver.kerberos.principal", "hbase/_HOST@FIELD.HORTONWORKS.COM"); 
		configuration.set("hbase.regionserver.keytab.file", "src/hbase.service.keytab"); 
		
		// this is needed even if you connect over rpc/zookeeper
		configuration.set("hbase.master.kerberos.principal", "hbase/_HOST@FIELD.HORTONWORKS.COM"); 
		configuration.set("hbase.master.keytab.file", "src/hbase.service.keytab");

hbase的master和regionserver 的keytab需要分别指出

详细可以看下这个人的代码

HBase-Example/HBaseClient.java at master · kartik-dev/HBase-Example · GitHub

4、java.net.SocketTimeoutException: callTimeout=60000, callDuration=68908: Call to xxx failed on local exception: org.apache.hadoop.hbase.exceptions.ConnectionClosingException: Connection to xxx is closing.

使用hbase hbck查看表状态OK
查看hbase服务端regionserver日志没有任何异常，无法定位到根因
查看客户端/etc/hosts文件ip映射与dns等都正常。
将客户端日志级别和服务端对应报错的regionserver日志级别修改为trace级别。等待问题复现。
复现后发现服务端有如下异常打印，此打印说明业务再运行过程中用户发生了改变，由cdm_user变成了saxppopt用户。cdm_user没有对应的hbase用户权限，从而导致认证异常。

问题解决参考

在hbase服务级别core-site.xml文件中自定义hadoop.proxyuser.sxappopt.hosts=*,hadoop.proxyuser. sxappopt.groups=*两个参数，保存后重启hbase，修改这两个参数后可能会引起其他的一些组件之间的认证问题。

5、Could not initialize class org.apache.hadoop.hbase.ipc.RemoteWithExtrasException$ClassLoaderHolder等类

原因是以为项目引用了appche的jar包

解决

3.1将appche的版本

拷贝CDH相关的配置文件

将Hadoop的core-site.xml以及Hbase的hbase-site.xml复制到项目的src/main/resources目录下（CDH 版的相关配置文件在/etc/{module}下）
在项目的src/main/resources目录下创建log4j.properties文件（防止日志报红）

6、HBase时写入数据大于10M后报错，

hbase.DoNotRetryIOException: Cell with size 14363531 exceeds limit of 10485760 bytes at org.apache.hadoop.hbase.regionserver.RSRpcServices.checkCellSizeLimit(RSRpcServices.java:944)

或者

java.lang.IllegalArgumentException: KeyValue size too large

这种情况是什么都没有配置的或程序中没有设置hbase.client.keyvalue.maxsize

第一个情况则是HBase默认一个单元格（cell）的数据大小是10M (10485760)，通过以下两个参数去调整：

hbase.client.keyvalue.maxsize

hbase.server.keyvalue.maxsize

将这两个值调整到合适的大小即可。

7、导入数据到HBase时错误：RetriesExhaustedWithDetailsException

原因是因为扩容后的节点hosts信息没有写到对应的etl服务器上。etl服务器拿到节点列表后部分解析不同配上对应的hosts就行了。另外提醒大家使用大数据集群的服务器就配上所有的节点。只配自己使用的节点就很容易遇到类似的问题

8.执行 hbase shell报错 hbase NameError: undefined local variable or method

只是因为没加单引号比如

restore_snapshot test_table

应该是
restore_snapshot 'test_table'

8.hbase backup create full hdfs://localhost:8020/data/backup
> Error: Could not find or load main class backup

backup 这功能早废弃了不知道写在官方文档里干嘛

9.File does not exist: /hbase/archive/data/

问题原因
该问题的原因是从源集群复制过来的文件在目标集群上不存在，检查目标集群，可发现目标集群的NameNode上有出现未找到的文件，也就是说文件原来是存在的，但过程中又被删除了。
解决办法
在快照未建立之前，HBase会定期清理archive目录下的数据。实测也正是如此，可将“org.apache.hadoop.hbase.master.cleaner.CleanerChore”的DEBUG日志打开，以观察文件被删除痕迹（修改HBase的log4j.properties）。
log4j.logger.org.apache.hadoop.hbase.master.cleaner.CleanerChore=DEBUG
CleanerChore线程清理archive目录是通过配置项hbase.master.hfilecleaner.ttl控制的，默认是5分钟（单位：毫秒），大表的文件迁移远超5分钟。将

hbase.master.hfilecleaner.ttl

调到足够大值后，问题消失。

CDH环境没有这个配置。直接写进hbase-site.xml 的 HBase 服务高级配置代码段里即可

10.hbase跨集群复制/hbase/.tmp/data/xxx FileNotFoundException

原因是因为在创建快照到跨集群复制过程中，部分StoreFile的位置发生了变动，以至不能正常寻址

暂时无解 major_compact 无效 webhdfs和hdfs都会出这个问题，网上似乎有修改源代码实现的，不知道行不行我的办法是规避此问题，快照到本地后再distcp到远程集群

11、service monitor未找到活动master 。查看hbase日志Recover lease on dfs file hdfs://hdfs-namenode-service:9000/hbase/MasterProcWALs/pv2-00000000000000000269.log

删除 /hbase/MasterProcWALs下的日志文件

hdfs dfs -rmr /hbase/MasterProcWALs/*

12、Region in transition (永久RIT) 异常解决4

Hbase版本：2.0

问题原因

hbase长时间出现RIT，并且发生RIT的Region是已经删除了的Hbase表，表未删除的情况下执行assgin可以消除该问题,表删除后，执行assgin 会提示超时，表的Region不存在无法执行该命令。

解决方法

Hbase 2.x 版本 RIT信息已经不再Zookeeper中保存

首先我们删除 hbase:meta 中的region元信息，该表已经不再在了，元信息也是没有用的垃圾数据。

上图框中的内容就是存在 meta表中的rowkey，我们直接去删除就可以

执行

deleteall 'hbase:meta','ods_temp:article_201946,201911148ba82019111417250_44.'
 Took 
 0.3505 seconds

1. 删除meta表数据

2. 停止Master服务

3. 删除/hbase/MasterProcWALs 下的文件.不删除该文件，master重启后还是会读取该日志文件

hdfs dfs -rm /hbase/MasterProcWALs/pv2-00000000000000000001.log

我们大概看下内容，发现包含RIT的信息

如果不删除该日志文件，我们重启master服务，会发现RIT还是存在，但是state变成了OFFLINE，server 变成 null

4. 启动master服务

发现已经没有RIT问题了

当RIT发生的时候，是执行不了 balance 的，所以永久RIT的状况要及时解决。

正常使用情况下的RIT问题基本不需要处理，这种永久性RIT问题出现的频率不会很高，删除元数据需谨慎，最好在测试环境测试后，再在生产环境使用。

13、hbase 重启master 报错 Could not find or load main class org.apache.hadoop.hbase.master.HMaster 和重启REST server 报错 classnotfoundexception org/apache/hadoop/hbase/util/VersionInfo

环境出问题了，jar包或者环境里的问题被改了。不用怀疑拿别的没问题的节点的jar包覆盖一下就行了

find /opt/cloudera/parcels/CDH/ -type f | sort | wc -l

find /opt/cloudera/parcels/CDH/ -type f | sort | md5sum

rsync 同步一下吧

14、TimeoutIOException: Failed to get sync result after msforringBufferSequence=, WALsystemstuck?

Call queue is full on /0.0.0.0:60020, too many items queued

这两个一般都在一起的，根据异常日志推测是消费队列(默认长度为10倍的Handler数)打满导致，Server端通过executeRpcCall()方法执行RPC远程调用，CallRunner消费次数超过"hbase.ipc.server.max.callqueue.length"配置值就会引起"too many items queued"异常：

尝试将这几个配置调大

hbase.regionserver.handler.count  #增加目标集群的replication请求处理的线程数
hbase.ipc.server.max.callqueue.size #默认值1G，建议业务修改配置

临时处理的话重启一下出问题的regionserver ，把请求分流掉

15、Hbase oldWAL日志异常增长，Hbase OldWAL目录占用空间比较大超过8T,。于是对OldWAL目录进行了清理，第二天发现这个目录又达到了几个T的数据量，分析发现这个目录第秒2G的速度增长，没有业务在大量写入操作。

对OldWAL目录下的数据进行清理，释放空间。
进入hbase master web ui 在页面Home查看是否有region在RIT状态
table Details查看是否有表报错信息，如果有进入具体的表查看是不有region处于大量的open和close操作。
切换到Procedures & Locks 页面查看是否有异常如：Locks卡住的Procedures
如果有region一直处于RIT状态，可以使用hbck2工具进行offline掉这个region后再现观察oldWAL目录是否还在增长。
在关闭处于RIT状态的region后目录还是在增长，切换到Procedures & Locks 页面，找到Lock的id 通过hbck2 工具bypass掉这个进程。
如果4、5操作过后还没有解决掉就需要强制删除这个表并且重建这个表来解决。
在强制删除这个有问题的表前要先对其做好备份（把表对应的region数据移走）。
在删除这个表后，再切换到Procedures & Locks 页面查看是否有Lock的进程，如果有就bypass掉，这时候oldWAL目录增长就会恢复正常。
恢复删除的表（建好表之后把之前的region数据移回来，再上线region）

Mumunu-

关注

0
点赞
踩
7

收藏

觉得还不错? 一键收藏
0
评论
HBase运维中遇到的问题

在hbase服务级别core-site.xml文件中自定义hadoop.proxyuser.sxappopt.hosts=*,hadoop.proxyuser. sxappopt.groups=*两个参数，保存后重启hbase，修改这两个参数后可能会引起其他的一些组件之间的认证问题。另外提醒大家使用大数据集群的服务器就配上所有的节点。该问题的原因是从源集群复制过来的文件在目标集群上不存在，检查目标集群，可发现目标集群的NameNode上有出现未找到的文件，也就是说文件原来是存在的，但过程中又被删除了。
复制链接

扫一扫