记录HBase手动删除Hadoop备份(archive)文件后,引发Hbase写入数据出错等一系列问题处理
由于需要规范HBase数据表命名,对测试环境的数据进行了重命名操作。
停掉所有服务后执行下面改名操作
# 禁用活跃用户表 disable 'DC_XXL:ACTIVE_USERS' # 创建快照 snapshot 'DC_XXL:ACTIVE_USERS', 'tony_snapshot' # 克隆快照为新的表(使用新名称) clone_snapshot 'tony_snapshot', 'DC_XXL:ACTIVE_USERS_LOG' # 按命名空间查看克隆的表是否存在 list_namespace_tables 'DC_XXL' # 查看快照 list_snapshots # 删除快照 delete_snapshot 'tony_snapshot' # 查看旧表详情 desc 'DC_XXL:ACTIVE_USERS' # 查看新表详情,比较两个表是否一致 desc 'DC_XXL:ACTIVE_USERS_LOG' # 禁用旧表 disable "DC_XXL:ACTIVE_USERS" # 删除旧表 drop 'DC_XXL:ACTIVE_USERS'
然后重新启动测试服务。
操作完后发现测试服务器的存储空间不足,想要删除一些数据占用,使用df -h查看各服务器的磁盘空间占用情况,发现Hadoop存储目录已占用了90%以上的空间,所以顺便使用命令查看一下Hadoop的空间使用情况
# 查看hadoop根目录各文件夹占用空间 hadoop dfs -du -h /# 查看hbase占用空间 hadoop dfs -du -h /hbase
通过命令一层层查看,可以发现主要是hbase占用了存储,而刚刚执行前面的命令操作后,在hbase目录下面发现主要存储空间占用的目录有:data(项目数据表存储目录)与 archive(存档目录),而archive目录一般存储的是备份用的,理论上来说是可以直接删除,所以网上查了一些资料说没问题后,就直接使用 rmr(hadoop dfs -rmr /hbase/archive/data/DC_XXL/ACTIVE_USERS)命令将里面的存档文件删除了,没想到引发了一系列的故障......
过了一会继续查看磁盘空间占用,发现磁盘使用在持续快速增长,很快有的服务器已达到100%
使用 hadoop dfs -du -h /hbase 查看发现,MasterProcWALs 目录突然间多了几十G,经查询这是HBase状态日志目录,进去将它们全部删除,发现磁盘占用还是100%没有变化
继续排查,使用 hadoop dfs -du -h / 发现,原来直接使用rmr删除后,hadoop会将文件移动到 /user/root/.Trash/Current/hbase/ 这个垃圾站目录下面
而这时在查看服务运行日志时,也发现了大量的IO异常
Hbase_thrift.IOError: IOError(message=b'org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after attempts=16, exceptions: Mon Jul 06 20:01:52 CST 2020, RpcRetryingCaller{globalStartTime=1594036912662, pause=100, maxAttempts=16}, org.apache.hadoop.hbase.NotServingRegionException: org.apache.hadoop.hbase.NotServingRegionException: DC_XXL:ACTIVE_USERS_LOG,4,1593765189585.73133efd2d876b7f7edabc3ab6709cae. is not online on slave2,16020,1594035938293 at org.apache.hadoop.hbase.regionserver.HRegionServer.getRegionByEncodedName(HRegionServer.java:3249) at org.apache.hadoop.hbase.regionserver.HRegionServer.getRegion(HRegionServer.java:3226) at org.apache.hadoop.hbase.regionserver.RSRpcServices.getRegion(RSRpcServices.java:1414) at org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2429) ......
从日志中可以看到,是由于写入数据时,所要写入的region下线所引发的IO异常,在浏览器中进入HBase web管理器(http://master:16010),可以看到所有节点都是在线的,拉到 Tables 位置,查看对应的数据表状态,会发现该表的Other Regions标识了出现问题的数量。
经过查找资料与思考分析,执行快照操作,HBase会在HDFS中创建一个和unix硬链接相同的存储文件,而执行镜像克隆操作时,实际上新表与旧表共用相同的数据块,新表只在data目录创建新表文件,但并不会复制region,只是通过linkfile定位旧表文件地址。当删除旧表以后,HBase应该会将旧表数据移动到 archive 目录下面,只有在新数据写入并提交compact时,才会数据迁移到新表文件中。所以执行快照和克隆操作是秒级,几百G的数据执行命令后立马结果就出来了。
而我直接删除了备份文件,数据并没有迁移完,导致某些region直接丢失了。
随后将回收站的文件重新移动到 archive 目录下面,使用 hbck 命令修复,发现修复失败,由于是测试数据只需要从kafka中生成最近一周的就可以了,且旧数据占用太多空间需要清理,所以没有继续研究修复,直接将它清除,决定创建新表运行相关服务批量重新生成测试数据。
进入hbase shell中,执行命令
disable 'DC_XXL:ACTIVE_USERS_LOG'
发现命令卡死,直到超时才退出,发现数据表禁用不了也删除不了。
登录 zookeeper ,删除对应的数据
# 连接zookeeper服务/usr/local/zookeeper/bin/zkCli.sh -server master:2181# 查看hbase数据表ls /hbase/table # 删除数据表 rmr /hbase/table/DC_XXL:ACTIVE_USERS_LOG
删除Hadoop存储的数据
# 查看hadoop的dfs文件 hadoop dfs -du -h /hbase/data/DC_XXL # 删除文件 hadoop dfs -rmr /hbase/data/DC_XXL/ACTIVE_USERS_LOG # 清除垃圾站文件 hadoop dfs -rmr /user/root/.Trash/Current/hbase/data/DC_XXL/ACTIVE_USERS_LOG
再次进入hbase shell,输入list已查看不到数据表了,输入命令创建新表
create 'DC_XXL:ACTIVE_USERS_LOG',{NAME=>'c',COMPRESSION=>'lz4',VERSIONS=>1},SPLITS=>['2','4','6','9']
这时直接提示:ERROR: Table already exists 异常信息,经过排查发现原来meta表还存储了数据表以及对应的region信息,需要一一清除干净才行
# 扫描meta表,查找当前数据表相关记录 scan 'hbase:meta',{STARTROW=>'DC_XXL:ACTIVE_USERS_LOG',ENDROW=>'DC_XXL:ACTIVE_USERS_LO~'}# 删除表记录命令(这一条命令必须在shell执行,脚本可能删不干净) deleteall 'hbase:meta','DC_XXL:ACTIVE_USERS_LOG'# 记录量少的话可以手动一条条删除 ......
批量删除 hbase:meta表数据表相关记录脚本
import happybase connect = happybase.Connection(host='master', port=9090, timeout=300000, autoconnect=True, compat='0.98', transport='buffered', protocol='binary') def scan(table, row_prefix=None, columns=None): t = happybase.Table(table, connect) scan = t.scan(row_prefix=row_prefix, columns=columns) data = [] for key, value in scan: result = {row.decode().replace('c:', '').lower(): value[row].decode() for row in value} result['pk'] = key.decode() data.append(result) return data def delete(table, rowkey): t = happybase.Table(table, connect) t.delete(rowkey) if __name__ == '__main__': columns = ['info:server'] row_prefix = 'DC_XXL:ACTIVE_USERS_LOG'.encode() result = scan('hbase:meta', row_prefix, columns=columns) print(len(result)) for row in result: pk = row.get('pk') print(pk) delete('hbase:meta', pk)
脚本执行成功后,需要在shell中执行前面的scan语句检查一次,看看是否全部都删除干净
然后重启hbase服务,进入shell中执行创建数据表语句,这次就可以执行成功了(不重启hbase服务,可能会影响数据表状态,然后产生大量的异常状态记录占用存储空间)
在这次事件中出现了几次错误操作,导致本次故障。由于之前也试过多次改名,并没有出现问题,导致本次操作时过于轻心。没有深入了解快照和克隆快照的底层原理,而网上查到的 archive 相关文章在不了解其背景的情况下,就以为可以直接删除文件,导致异常的发生。当存储空间不足时,没有全面排查了解存储空间丢失原因,就进行一些处理,导致直接恢复删除文件并没有修复问题。而对hbase一些命令的底层运行原理不了解,也造成一些操作上的误判。好在这只是测试环境,数据丢失影响不大,接下来需要深入研究hbase各方面的运行机制,避免这种低级问题的发生。
- 点赞
- 收藏
- 关注作者
评论(0)