HBase Meta 元信息表修复实践
作者：vivo 互联网大数据团队 - Huang Guihu、Chen Shengzun
HBase 是一款开源高可靠、高可扩展性、高性能的分布式非关系型数据库，广泛应用于大数据处理、实时计算、数据存储和检索等领域。在分布式集群中，硬件故障是一种常态，硬件故障可能导致节点或者集群级别服务中断、meta 表损坏、RIT、Region 空洞、重叠等问题，如何快速修复故障恢复业务尤其重要，本文章主要是围绕 HBase meta 表常见的故障以及对应解决方案进行描述。
一、背景
相信做过 HBase 开发、运维相关工作的朋友多多少少都有这样感受，HBase 作为分布式非关系型数据库中的佼佼者不仅稳定、性能高、安装扩容等运维也非常简单，但是 HBase 缺乏成熟监控系统对故障排查极不友好。如果缺乏对 HBase 全面了解在应对日常故障经常束手无策，小编们作为运维大大小小 20+个 HBase 集群涉及 1.x~2.x 等版本，经历过 meta 表损坏无法正常上线、Region 重叠、Region 空洞、权限丢失等线上问题毒打，也带着各种各样问题从 HBase 源码中寻求正确答案，本文是小编们多次故障中总结出的 meta 表常见解决方案。
二、HBase meta 元信息表
HBase meta 表又称为 catalog 表是一张特殊的 HBase 表，它存储了 HBase 集群所有 Region 和其对应的 RegionServer 信息，元信息表的数据正确性对于 HBase 集群的正常运行至关重要，因此需要保证元信息表的数据正确是集群稳定运行的必要条件。如果 meta 表出现数据不一致将会导致 RIT（Region In Transition）甚至出现由于 HMaster 无法正常初始化导致集群无法正常启动，由此可见 meta 表在 HBase 集群中重要性，下面我们围绕 meta 表结构、数据格式、启动流程进行解析它（本文主要围绕 HBase 2.4.8 版本，也会穿插 HBase 1.x 版本）。
2.1 meta 表结构
meta 表主要包括 info、table、rep_barrier 三个列族分别记录 Region 信息、表状态：
2.2 meta 表加载流程
通过上述 meta 表结构我们对该表有一个整体认识，做过 HBase 运维的朋友相信都有这种经验有一些集群启动比较快、有一些集群启动比较慢，甚至有时候由于操作不当集群重启时候一直卡在 meta 表加载无法继续执行后续流程。如果我们对 meta 表加载流程有一个整体了解之后我们将对每一个集群启动时间多多少少都有一个心理预期，以下是 meta 表加载相关流程：
通过以上 meta 表加载流程图我们很好找到为什么有一些集群启动比较慢、有一些集群启动失败原因了，下面我们针对两类场景进行分析：
集群启动慢：
通常新集群或者表数量比较少集群往往启动速度比较快，表数量比较多的集群往往启动相对慢很多，甚至有一些集群启动 HMaster 需要 15~30 分钟，有时候集群启动时间比较长让人不免怀疑是不是集群出现问题了，为什么那么长时间无法进入正常状态呢？在整个加载流程中出现两个耗时比较长地方。
预加载所有表描述符：需要把 HBase 数据目录全部扫描一遍并解析出.tabledesc 目录下面数据文件存放 HMaster 内存中，如果表数量比较多（超过 10000 张表）这一过程往往需要十来分钟，如果我们看 HMaster 页面出现“Pre-loading table descriptors”字样时说明该集群处于预加载阶段我们只需耐心等待即可，因为还没有到 meta 表加载阶段。
上线业务表 Region：meta 表数据大小通常在几十 M 到几百 M 之间 Region 打开时间比较快（秒级），集群启动阶段需要检查并上线 Offline Region，如果想加快打开速度可以适当调整 hbase.master.executor.openregion.threads（默认值为 5）值。
集群启动失败：
meta 表上线失败：当 default 资源组的 HRegionServer 挂掉之后，重启后机器的 startcode 变化之后，meta 的数据分片找不到打开节点，导致集群启动失败。
三、如何修复 meta 表
由于 HBase 集群状态主要是通过 meta 表去维护，如果 meta 表出现了损坏或错误，将会导致 HBase 集群的不可用和面临数据丢失风险。我们知道 meta 表数据一致性非常重要那么什么情况会出现数据不一致呢？（HBase 2.4.8 修复命令参考 hbase-operator-tools 工具）。
RegionServer 宕机或异常：当 RegionServer 宕机或异常时，meta 表中存储的 Region 和 RegionServer 信息可能会出现错误或丢失。
数据损坏或错误：当 meta 表中的数据损坏或错误时，可能会导致 HBase 集群的不可用和数据丢失。
非法操作：当对 meta 表进行非法操作时，例如删除或修改 meta 表中的数据，可能会导致 meta 表出现错误或丢失。
meta 表故障只是一直比较笼统的说法，我们可以根据类型可以大致分为长时间 RIT、Region 空洞、Region 重叠、表描述文件丢失、meta 表 hdfs 路径为空、meta 表数据丢失等，下面我分别对这些类型故障进行分析并进行修复：
3.1 RIT
RIT（Region In Transition）是指 HBase 集群中正在进行状态转换，以下操作都会引起 HBase 集群中 Region 的状态发生变化，例如 RegionServer 宕机、Region 正在进行拆分、合并等操作，Region 状态主要是包括以下十二种状态以及转化图：
为了更加清晰 Region 状态装换我们根据操作类型可以分为 assign、unassign、split、merge，如果操作过程出现 RegionServer 宕机或异常、数据损坏或错误都会出现 RIT，RIT 虽然是在 HBase 运维中经常遇见的问题，但是如果清楚底层逻辑将会比较容易处理 RIT 问题，HBase 集群都具备 RIT 修复能力大部分情况都不需要手工介入都能正常恢复，出现长时间 RIT 才需要人工介入处理，那什么是长时间 RIT？为什么会出现长时间 RIT 呢？
如果用过 HBase 1.x 和 HBase 2.x 版本明显感觉 HBase 2.x 比较少出现 RIT，其实 Region 的操作主要是通过 AssignmentManager 类进行 Region 转移，对比两个版本代码我们发现 hbase.assignment.maximum.attempts 参数（assign 重试次数）在两个版本的默认值不一样，HBase 2.4.8 重试次数为最大整数 Integer.MAX_VALUE（而 HBase 1.x 中该值默认为 10），这就是为什么在 HBase 2.x 中比较少出现长时间 RIT 原因。
RIT 处理方法：
建删大表都会出现 RIT 主要是由于 Region 数量比较多集群压力比较大导致 assign、unassign 响应时间过长导致，针对这类问题一般不需要人工介入 HBase 可以自愈。
如果集群版本为 1.x 可以适当调整 hbase.assignment.maximum.attempts 值增加重试次数，如 FAILED_OPEN、FAILED_CLOSE 通常都可以自愈，或者手工执行 assign 命令一个个 Region 分配上线（如果 Region 比较多切换 HMaster 修复）。
如果出现 Region 分配失败，不存在 RegionServer 时候，手工 assign 都没办法恢复，如 Region 被分配到 bogus.example.com,1,1 节点只能通过切换 HMaster 恢复。
问题思考：
为什么 Region 手工介入都不能正常上线切换 HMaster 就能恢复呢？（参考 HMaster 启动流程 TransitRegionStateProcedure、HMaster 类源码）
3.2 Region 空洞
我们创建 HBase 表时如果细心去分析 Region 规律会奇怪发现 Region startkey 和 endkey 属于左闭右开的连续区间，如果突然这些区间少了一块（如下图）将会出现什么问题呢？
出现上面情况就是我们常说的 Region 出现空洞，如果用 HBase hbck 工具检查会看到这样错误信息 ERROR: There is a hole in the region chain between 01 and 02. You need to create a new .regioninfo and region dir in hdfs to plug the hole，HBase 集群出现空洞往往是没办法自愈需要人工干预才能恢复正常，既然我们知道少了一个 Region 我们如果把空白区间的 Region 补回去不就可以了吗？正常做法是先把空白的 Region 补充回去，并检查 meta 表信息是否正确，最后再上线 Region，如果这一系列操作都通过手工去实现不仅仅容易出错操作时间也很长，下面分别介绍一下不同版本 HBase 修复方法，其实不同版本处理方法虽然有一点差异但是处理流程都一样。
Region 空洞处理方法：
（1）HBase 1.x 修复方法
HBase hbck –fixHdfsHoles：在 hdfs 上创建空 Region 文件路径
HBase hbck -fixMeta：修复该 Region 所在 meta 表数据
HBase hbck –fixAssignments：上线修复之后 Region
或者 HBase hbck –repairHoles 相当于（fixHdfsHoles、fixMeta、fixAssignments）几个组合起来
（2）HBase 2.4.8 修复方法(参考后面 hbase-operator-tools 工具)
由于 HBase 2.4.8 没有提供相关的命令去添加 Region 目录操作方面相对麻烦一点，其实 HBase 2.4.8 里面很多工具类都提供创建 Region 方法，hbase-server-2.4.8-test 包中 HBaseTestingUtility 类都提供了操作 Region 相关的入口，下面我们的解决方法主要是围绕该方法进行恢复。
extraRegionsInMeta -fix：首先把 meta 表中 hdfs 目录不存在记录先删除
HBaseTestingUtility.createLocalHRegion：创建 hdfs 文件路径保证 Region 连续性
addFsRegionsMissingInMeta：再往 meta 表添加新建 Region 信息（添加成功之后会返还 Region id
assigns：最后把新加入 Region 上线
3.3 Region 重叠
既然 Region 会出现空洞那么会不会存在这种情况，相同的 startkey、endkey 出现多个呢？答案是肯定的如果多个 Region startkey、endkey 是一样的 Region，那么我们将这种情况称作 Region 重叠。Region 重叠在 HBase 中比较难模拟同时也是比较难处理的一种问题。如果我们做 hbck 检查时候出现这种日志 ERROR: Multiple regions have the same startkey: 02
另外一种重叠 Region 跟相邻的分片其中一个或两个的 rowkey 范围有交集，这类问题统称 overlap 问题，针对这个比较难的场景我们通过自研工具模拟 overlap 问题复现并一键修复 overlap(折叠)和 hole(空洞)问题。
overlap 问题模拟功能
Region 重叠问题实际就是两个不同 Region，rowkey 的范围有交集，比如 Region01 的 startkey 和 endkey 是（01,03），同时另外一个 Region02 的范围是（01,02），这样两个 Region 出现了交集（01,02），hbck 检测就会报 overlap 问题。
重叠问题在生产环境只有在 Region 分裂和机器同时挂掉情况下，才会出现 overlap 问题，出现条件比较苛刻，复现问题比较困难，能够复现问题对后续修复和故障演练都很重要，overlap 问题复现原理：
overlap 问题复现
1）生成一个 rowkey 范围重叠的 Region 分片：
2） 将 overlap 问题 Region 移动到表目录下：
3） 删除正常的表 migrate:test_hole2 的 meta 表信息：
4）重构 overlap 问题表元数据信息：
5） 重启集群后 hbck 报告 Region 重叠 c8662e08f6ae705237e390029161f58f，成功复现重叠问题
方法一：一键修复 overlap(重叠)和 hole(空洞)
适用于折叠数量不超过 64 个情况下，利用自研工具 hbase-meta-tool 可以将相邻 Region 有 rowkey 交集的范围合并，有空洞缺失范围生成新的 Region，这样就能修复问题，问题修复原理如图：
1）修复集群的重叠与空洞问题：
方法二：大规模折叠修复
适用大规模折叠超过几千个或者上万个情况修复服务器端报异常，采取一下修复手段
1）一键清除有折叠问题表的元数据：
2）备份原始表数据：
3）删除原始表和导入备份数据每个 Region 分片：
3.4 meta 表数据修复
HBase 线上集群我们可能会遇到下面棘手问题：
coprocessor 配置错误的表,找不到协处理器路径，加载 Region 过程中找不到 jar，导致集群反复挂掉，drop 命令也删除不掉；
HBase meta 表元数错误，startcode 不对，上线过程中找不到服务器的表,表始终不能上线。
我们要在保证不影响集群其他表服务的情况下，单独不停服修复问题表。
问题表的 meta 数据修复
1）假设表 migrate:test1 有问题，可以一键删除问题表元数据：
2）读取 hdfs 表的.regioninfo 文件夹内容，一键重构正确的元数据：
3.5 meta 损坏
上述 5 种情况都是在 meta 表正常上线的前提下面修复，如果 meta 表数据损坏无法上线我们应该怎么修复呢？通常我们都会想到重建 meta 表再把 Region 信息写入 meta 表，如果集群处于下线状态 HBase shell 或者 HBase api 通常是无法执行 create 建表。
我们分析 meta 表初始化类 InitMetaProcedure 发现 meta 表创建流程大致分两步走：
1）创建 Region 目录已经.tabledesc 文件
2）分配 Region 并上线。
InitMetaProcedure 核心源码：
InitMetaProcedure
我们可以参照 InitMetaProcedure 代码逻辑编写相应工具进行建表上线操作，meta 表上线之后我们只需要把每张表 Region 信息写入 meta 并对所有 Region 进行 assign 上线即可恢复集群正常状态。通过以上流程我们发现 meta 表修复流程也并非那么复杂，但是如果生产环境表数量比较多或者个别大表 Region 数成千上万那么手工添加就变的非常耗时，我们下面介绍一直相对比较简单的解决方法（HBase 1.x hbck 工具、HBase 2.x hbase-operator-tools），下面我们看一下离线修复处理流程。
HBase 1.x 修复方法
停止 HBase 集群
sudo -u hbase hbase org.apache.hadoop.hbase.
util.hbck.OfflineMetaRepair -fix
重启集群完成修复。
HBase 2.4.8 修复方法(hbase-operator-tools 工具)
1）根据 hdfs 路径自动生成 meta 表
停止 HBase 集群
sudo -u hbase hbase org.apache.hbase.
hbck1.OfflineMetaRepair -fix
重启集群完成修复。
2）单表修复方法
删除 zookeeper 中 HBase 根目录
删除 HMaster 、RegionServer 所在 hdfs WALs 目录
重启集群此时 meta 没有数据，集群无法进入正常状态
执行添加 Region 命令把 hbase:namespace、hbase:quota、hbase:rsgroup、hbase:acl 四字表添加到集群，添加完成之后日志将会打印 assigns 后面跟随这几张表的 Region，需要记录下这些 Region 以便下一步 assign 操作。
把上一步添加打印 Region 上线
业务表上线（只需要重复 4-5 步骤把业务表逐步上线）
注意事项
（如果业务表 Region 比较多第 5 不 assign 不能把 Region 全部上线成功，需要把表现 disable 再 enable 就可以正常上线）
备注：hbase-operator-tools OfflineMetaRepair 工具存在以下几个 bug 需要修复。
1、HBaseFsck createNewMeta 方法创建 meta 表缺少.tabledesc 文件
修改前：
修改后：
2、HBaseFsck generatePuts 默认 Region 状态为 CLOSED 因为 HMaster 重启时候只上线 OFFLINE 状态 Region（如果为 CLOSED 需要手工一个个 Region 上线工作量非常庞大）
修改前：
修改后：
缺点
1）离线修复需要停止集群服务，停止时长根据修复时间而定（大概在 10-15 分钟左右）。
2）如果其中存在 Region 重叠、空洞等问题需要手工处理完成再执行 OfflineMetaRepair 离线修复命令。
四、hbase-operator-tools 工具
hbase-operator-tools 是 HBase 中的一组工具，用于协助 HBase 管理员管理和维护 HBase 集群。hbase-operator-tools 提供了一系列工具，包括备份和恢复工具、Region 管理工具、数据压缩和移动工具等，可以帮助管理员更好地管理 HBase 集群，提高集群的稳定性和可靠性。需要编译源码之后才可以使用，源码git地址。常见命令如下：
五、总结
HBase meta 表的数据正确性对于 HBase 集群的正常运行至关重要，如何保证 meta 表数据正确以及数据损坏之后快速修复变的极为重要，如果对 meta 没有全面认识每次集群出现故障将会措手无策。本文主要是围绕 meta 表结构加载流程、常见问题以及相关的修复方法分析，针对以上修复方法我们可以粗略分为以下两大类：
在线修复：meta 表可以正常通过 hbck、自研工具进行 meta 表数据修复保证数据完整性。
离线修复：meta 表无法正常上线根据 hdfs 中 Region 信息重构 meta 表恢复 HBase 服务。
如果集群规模比较大离线修复时间比较长集群需要长时间停止服务，大部分情况业务是不能容忍可以结合实际情况进行表级别修复（除非 meta 表文件损坏不能正常上线），建议定时对集群做 hbck 检查一旦出现元信息不一致情况尽快修复避免问题扩散（如元信已经错乱做集群重启错乱 Region 将会由于 assign 失败导致其他 Region 无法正常上线），如果定时巡检发现有业务表出现元信息错乱情况直接重 meta 表把该表信息删除并根据根据 hdfs 路径信息重新把 Region 加回 meta 表（addFsRegions-
MissingInMeta 命令可以根据 hdfs 路径把 Region 正确添加到 meta 表）。
参考文章：
版权声明: 本文为 InfoQ 作者【vivo互联网技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/629936e4d4c6c8be8722b7bc6】。文章转载请联系作者。
官方公众号：vivo互联网技术，ID：vivoVMIC 2020-07-10 加入
分享 vivo 互联网技术干货与沙龙活动，推荐最新行业动态与热门会议。
评论