【HBASE】记一次HBase进行数据迁移，重建元数据

Meepoljd

已于 2022-05-13 14:46:48 修改

阅读量1.3k

点赞数

分类专栏：运维大数据文章标签： hbase big data hadoop

于 2022-05-12 11:42:55 首次发布

本文链接：https://blog.csdn.net/Meepoljd/article/details/124719779

版权

运维同时被 2 个专栏收录

57 篇文章 2 订阅

订阅专栏

大数据

35 篇文章 0 订阅

订阅专栏

记一次HBase进行数据迁移，重建元数据

前情提要
正文
后续的表修复
拷贝过程的其它问题
- Distcp失败
- Distcp调优

前情提要

由于早期部署人员和架构上留下的大坑，我们集群的RegionServer组件和其他组件共机严重，服务器负载高时，直接会导致RegionServer断联，出现永久RIT的情况，而且hbck无论怎么修复都不行，虽然业务对hbase的数据需求不是特别的严格，但是有时候应付演示也是要用的，在现有架构难以变动的情况下，想到提供一个小型的同版本集群，进行原始数据拷贝和region重建的工作进行尝试。

正文

数据迁移

首先要将远端Hbase存在HDFS上的数据进行迁移，这里直接使用distcp工具进行拷贝，拷贝前先确认对端的数据和本地要拷贝的数据目录，一般来说都是/hbase/data/default/{表名}这样的路径:
在这里插入图片描述
为了减少对生产环境业务的影响，我的distcp工作都在新集群进行。这样mapreduce是使用新集群的资源运行：

hadoop distcp hdfs://cluster_old/hbase/data/default/tablename /hbase/data/default/

在这里插入图片描述
distcp执行期间会产生临时文件，等待任务的最终完成即可：

完成需要的表的拷贝后，此时进入hbase执行list命令已经能看到表名了，但是不可以进行查询，因为还没重建表的元数据：

重建元数据

这里也是直接使用hbase hbck工具进行元数据的重建，这里采用的是单个表单个表的进行：

 hbase hbck -repair tablename

在这里插入图片描述

测试查询

随便scan一下，因为现在locality不够，所以可能查询会比较慢，这个会慢慢好的：
在这里插入图片描述

后续的表修复

Multiple regions have the same startkey

最大的问题就是，原来的数据就已经有问题了，导致我迁移过来以后重建元数据依旧有问题！最恶心的就是Multiple regions have the same startkey这个，还没发用hbck修复，写了个生成修复命令的脚本：

#-*- coding:utf-8 -*-
#!/usr/bin/python
import os
import commands

def make_json(file):
    t = dict()
    with open(file) as f:
        for item in f:
            if "Multiple regions have the same startkey" in item:
                item = item.strip('\n')
                item = item.split(" ")
                region = item[2].strip(')')
                startkey = item[-1]
                if startkey not in t.keys():
                    t[startkey]=[]
                t[startkey].append(region)
    return t

def split_hdfs_result(l):
    t = dict()
    for i in l:
        k = i.split()[1]
        v = i.split()[0]
        t[k]=v
    return t


def check_hdfs_size(t):
    # 返回一个
    allpathsize_map = split_hdfs_result(commands.getoutput("hadoop fs -du /hbase/data/default/dm_user_perception_area_mark_d").split('\n'))
    # 检查hdfs文件大小
    for i in t.keys():
        maxregion = ''
        maxsize = 0
        for region in t[i]:
            # 循环处理region路径
            path = os.path.join("/hbase/data/default/dm_user_perception_area_mark_d", region.split('.')[-2])
            # 赋值最大的目录
            try:
                if int(allpathsize_map[path]) > int(maxsize):
                    maxregion = region 
                    maxsize = allpathsize_map[path]
            except KeyError as e:
                continue
        while maxregion in t[i]:
            t[i].remove(maxregion)
    return t
        
            

def make_shell(t):
    # 生成清理脚本
    for k, v in t.items():
        li = list(set(v))
        for region in li:
            for i in ['info:regioninfo', 'info:seqnumDuringOpen', 'info:server', 'info:serverstartcode']:
                print("delete 'hbase:meta','{region}','{colum}'".format(region=region, colum=i))
                pass
    
    for k, v in t.items():
        li = list(set(v))
        for region in li:
            path = os.path.join("/hbase/data/default/dm_user_perception_area_mark_d", region.split('.')[-2])
            print("hadoop fs -rm -r {path}".format(path=path))
        

if __name__ == "__main__":
    a=make_json("hbase.log")
    a=check_hdfs_size(a)
    make_shell(a)

该脚本会在完成后打印出需要分别在hbase shell和hdfs中执行的命令：
在这里插入图片描述

Region not listed in hbase:meta or deployed on any region server.

修复使用fixMeta进行：

hbase hbck -fixMeta

Region state=FAILED_OPEN

如果出现这种问题，最好hbck detail一下，查看具体原因：

hbase hbck -details tablename

在这里插入图片描述
比如我这里就出现了一个问题，这个可以直接使用hbck修复：

hbase hbck -fixReferenceFiles tablename

在这里插入图片描述

Region not deployed on any region server

hbase hbck -fixAssignments tablename

在这里插入图片描述

There is an overlap in the region chain

hbase hbck -fixHdfsOverlaps tablename

Region found in META, but not in HDFS or deployed on any region server

hbase hbck -fixMeta tablename

在这里插入图片描述

拷贝过程的其它问题

Distcp失败

有一个表在拷贝的时候，出现异常，任务刚提交没多久就失败，报错是有没法get对应的文件：
在这里插入图片描述
第一个反映是块有问题，然后就去hbck了一下，结果是正常：

这下整蒙了，然后我本地get了一下，文件就是拿不下来。尬了，经过查阅资料，看到一个博客说了这个问题：参考博文

这次检查出来不少文件打印显示都是 openforwrite状态，而且Status为CORRUPT。经测试发现，这些文件无法get和cat。所以这里的“ Cannot obtain block length for LocatedBlock ”结合字面意思讲应该是当前有文件处于写入状态尚未关闭，无法与对应的datanode通信来成功标识其block长度。

于是我也尝试使用openforwrite检查，发现确实对应的块是CORRUPT状态：
在这里插入图片描述
于是我直接对待拷贝数据的全目录再进行了一次扫描，对于异常数据直接delete：

处理以后再次进行同步旧不会报错了：

数据删除是敏感操作，笔者是因为集群数据本身异常不能提供服务，经过沟通确认后以最快保证业务恢复为目的而进行的删除操作，作为运维人员一定要对数据安全保有敬畏之心！

Distcp调优

使用Distcp过程中，遇到数据同步比较慢的情况，尝试了一些参数，直观感受是提高了同步速度，记录一下：

增加map数，-m 100，默认会使用20个map，在数据量较大的时候，提速效果明显；
-Dmapreduce.map.memory.mb=4096 增加map的容器内存，默认是1024M；
-Dmapreduce.reduce.memory.mb=4096 增加reduce的容器内存，默认是1024M；

最终使用命令：

hadoop distcp -Dmapreduce.map.memory.mb=4096 -Dmapreduce.reduce.memory.mb=4096 -m 100 hdfs://10.1.1.1:9000/hbase/data/default/tablename /hbase/data/default/