HBase运维基础——元数据逆向修复原理

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
简介: 鉴于上次一篇文章——“云HBase小组成功抢救某公司自建HBase集群,挽救30+T数据”的读者反馈,对HBase的逆向工程比较感兴趣,并咨询如何使用相应工具进行运维等等。总的来说,就是想更深层理解HBase运维原理,提高运维HBase生产环境的能力,应对各种常见异常现象。

背景

    鉴于上次一篇文章——“云HBase小组成功抢救某公司自建HBase集群,挽救30+T数据”的读者反馈,对HBase的逆向工程比较感兴趣,并咨询如何使用相应工具进行运维等等。总的来说,就是想更深层理解HBase运维原理,提高运维HBase生产环境的能力,应对各种常见异常现象。不同的读者对hbase的了解程度不同,本文不打算着重编写一个工具怎么使用,而是从HBase的运维基础知识介绍开始讲解。为了能帮助大部分读者提高HBase运维能力,后续会写个“HBase运维系列” 专题系列文章,欢迎到最下方扫码关注钉钉交流。

5d8291a7eaad73d5ee198c6f017867597e43a164

介绍

    相信很多自建HBase的企业会经常碰到各种各样的hbase运维问题。比如使用HBase的时候,HBase写入一段时间后开始RegionServer节点开始挂掉,重启RegionServer发现启动很慢,很多region出现RTI问题,导致读写某个region的业务hang住了 。还有一些人的HBase集群多次运维尝试后,直接HBase启动不了了,meta表上线就开始报错,导致最终业务不能正常上线运行等等系列问题。本文就HBase运维的原理基础开始入手,重点讲解数据完整性,以及元数据“逆向工程”恢复数据完整性的原理方法。开启后续一系列的HBase运维知识讲解。

HBase目录结构

    本文就1.x版本进行讲解,不同版本大致相通。HBase在HDFS上会单独使用一个目录为HBase文件目录的根目录,通常为 “/hbase”。基于这个目录下,会有以下目录组织结构:


/hbase/archive (1)
/hbase/corrupt (2) 
/hbase/data/default/TestTable/.tabledesc/.tableinfo.0000000001 (3)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/info/2e58b3e274ba4d889408b05e526d4b7b (4)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/recovered.edits/340.seqid (5)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.regioninfo (6)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.tmp (7)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.splits (8)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.merges (9)
/hbase/data/hbase/acl (10)
/hbase/data/hbase/meta (11)
/hbase/hbase.id (12)
/hbase/hbase.version (13)
/hbase/MasterProcWALs (14)
/hbase/oldWALs (15)
/hbase/.tmp (16)
/hbase/.trashtables/data (17)
/hbase/WALs/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com,16020,1523502350378/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com%2C16020%2C1523502350378.default.1524538284034 (18)

(1) 进行snapshot或者升级的时候使用到的归档目录。compaction删除hfile的时候,也会把就的hfile归档到这里等。

(2) splitlog的corrupt目录,以及corrupt hfile的目录。

(3) 表的基本属性信息元文件tableinfo。

(4) 对应表下的hfile数据文件。
(5) 当splitlog发生时,一个RS的wal会按照region级别split WALs写到对应目录下的的recovered.edits目录上,使得此region再次被open的时候,回放这些recovered.edits 日志。

(6) regioninfo文件。

(7) compaction等的临时tmp目录。

(8) split时临时目录,如果上次region的split没有完成被中断了,这个region再open的时候会自动清理这个目录,一般不需要人工干预。

(9) merges时的临时目录,和split一样,如果没有正常完成的时候被中断了,那么他会在下次被open的时候自动清理。一般也不需要人工干预。

(10) acl 开启HBase权限控制时的权限记录系统表

(11) meta 元数据表,记录region相关信息

(12) hbase.id 集群启动初始化的时候,创建的集群唯一id。可以重新fix生成
(13) hbase.version hbase 软件版本文件,代码静态版本,现在都是8
(14) master执行过程程序的状态保存,用于中断恢复执行使用。

(15) oldWALs 历史wal,即wal记录的数据已经确认持久化了,那么这些wal就会被移到这里。splitlog完成的那些就日志,也会被放到这里。

(16) tmp 临时辅助目录,比如写一个hbase.id文件,在这里写成功后,rename到 /hbase/hbase.id

(17) /hbase/.trashtables/data 当truncate table或者delete table的时候,这些数据会临时放在这里,默认1小时内被清

(18) 记录着一台RegionServer上的WAL日志文件。可以看到它是regionserver名字是有时间的,即下一次启动时RS的wal目录就会使用新的目录结构存放wal,这个旧的RS wal 目录就会被splitlog过程拆分回放


HBase涉及的主要文件及用途


HDFS静态文件,HDFS上的HBase 数据完整性

    1. hfile文件:数据文件,目前最高版本也是默认常用版本为 3。 hfile文件结构细节可以参考官网http://hbase.apache.org/book.html#_hfile_format_2。我们这里逆向生成元数据主要使用到了HFile fileinfo的firstkey、lastkey信息。

    2. hfilelink文件: 在hbase snapshot时用到, migration upgrade 也会使用到。很少碰到这类文件的运维问题,这里不作过多介绍。

    3. reference文件:用来指定half hfile,一个region有reference时,这个region不能split。split/merge会创建这个。进行compaction后生成新的hfile后,会把这个reference删除。hfile的reference文件名格式一般是 hfile.parentEncRegion。如:/hbase/data/default/table/region-one/family/hfilename。其region-two有reference hfile文件名格式为:/hbase/data/default/table/region-two/family/hfile.region-one 通常无效引用就是 region-one的hfile不存在了,那么这个引用就会失效。他的修复方法一般是把reference无效的引用移除。

    4. ".regioninfo" 文件,保存着 endkey/offline标志/regionid/regionName/split标志/startkey/tablename等

    5. tableinfo文件这类文件保存着 tableName/table属性信息/table级别config信息/family信息。其中family信息保存着 famliyName/famiy属性/famliy级别config信息等。

通常,table属性有:REGION_MEMSTORE_REPLICATION,PRIORITY,IS_ROOT_KEY等,一般这些属性默认也是根据配置的一样。family属性有:BLOCKSIZE,TTL,REPLICATION_SCOPE等,一般属性是根据配置使用默认的。

    6. hbase:meta表数据内容格式

        regionname, info:regioninfo, regioninfo的encodeValue值

        regionname, info:seqnumDuringOpen, 序列号

        regionname, info:server, region所在的server名

        regionname, info:serverstartcode, regionserver 启动的timestamp


元数据逆向生成原理

    上述介绍的数据文件中,HBase的主要的元数据主要由meta表、tableinfo、regioninfo构成。这里的逆向生成元数据指的是,根据数据hfile数据文件,反向生成regioninfo/tableinfo/meta表的过程。

1. 逆向生成tableinfo文件

    case1. 通过从master进程内存中的tabledescritor cache 完整恢复tableinfo文件,此时恢复的tableinfo是完整的,和之前的完全一样。

    case2. 当cache中没有加载过此表的tableinfo时,修复过程只能从表的目录结构list所有familyNames 来恢复tableinfo,这个时候只能得到的是列簇的名字,恢复tableinfo文件内容中,除了表名、列簇名一致,其他的属性均采用默认值。这个时候如果运维人员知道有什么属性是自定义进去的,那么就需要要手动再次添加进去。

2.  逆向生成regioninfo文件

    hfile 中的fileinfo读取firstkey/lastkey 排好序,得到region下所有hfile的最大rowkey和最小rowkey,并根据tableinfo中的表名 完整恢复  regioninfo文件。主要这里只能恢复 表明/startkey/endkey,  其他属性如:offline标志,regionName,split标志,hashcode等均使用代码生成或者配置的默认值。

3. 逆向填充meta表行

    regioninfo文件序列化,填入meta表 info:regioninfo 列,并同时写入默认的server,等它被再次open的时候,重新分配region到实际的regionserver上,并更新这里的数据行。

    逆向工程除了上面的直接文件、数据内容修复外,还涉及到数据的完整性其他方面修复。一个表示由无穷小的rowkey到无穷大的rowkey范围组成,还可能会发生的问题如:region空洞、region重叠现象,如:

7cf7f09077aadde2c279dd95133908d9bd33a29c


    如果有region空洞的时候,就会使用他们的空洞边界作为startkey/endkey,再修复创建一个region目录及目录下的regioninfo文件。如果是region重叠,则会把重叠的region进行合并,取所有region的最大最小rowkey作为merge后新region的最大最小rowkey。

元数据工具修复

    元数据的缺少或者完整性有问题,会影响系统运行,甚至集群直接不可用。最常见的如 meta表上线失败,region 上线open失败等。这里介绍两个工具,​工具一: hbase hbck 在线修复完整性修复元数据信息,​工具二:OfflineMetaRepair 离线重建 hbase:meta 元数据表。

在线hbck修复:

​前提:HDFS fsck 确保 hbase跟目录下文件没有损坏丢失,如果有,则先进行corrupt block 移除。

​步骤1. hbase hbck 检查输出所以ERROR信息,每个ERROR都会说明错误信息。

​步骤2. hbase hbck -fixTableOrphones 先修复tableinfo缺失问题,根据内存cache或者hdfs table 目录结构,重新生成tableinfo文件。

​步骤3. hbase hbck -fixHdfsOrphones 修复regioninfo缺失问题,根据region目录下的hfile重新生成regioninfo文件

​步骤4. hbase hbck -fixHdfsOverlaps 修复region重叠问题,merge重叠的region为一个region目录,并从新生成一个regioninfo

​步骤5. hbase hbck -fixHdfsHoles 修复region缺失,利用缺失的rowkey范围边界,生成新的region目录以及regioninfo填补这个空洞。

​步骤6. hbase hbck -fixMeta 修复meta表信息,利用regioninfo信息,重新生成对应meta row填写到meta表中,并为其填写默认的分配regionserver

​步骤7. hbase hbck -fixAssignment 把这些offline的region触发上线,当region开始重新open 上线的时候,会被重新分配到真实的RegionServer上 , 并更新meta表上对应的行信息。


离线OfflineMetaRepair重建​:

前提:HDFS fsck 确保 hbase跟目录下文件没有损坏丢失,如果有,则先进行corrupt block 移除

​步骤1: 执行 hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair -fix


    最后,两个工具使用说明都比较详细,经过上面的基础介绍,相信都会看的懂的。这里不对工具再细致说明,工具的说明可以参考官网或者工具提示。​题外话,有些开源组件设计的时候,向hbase元数据文件写入一些特有的信息,但是并没有修改到hbase工具的修复工具,或者它自己没有维护修复工具,如果这类文件损坏、丢失了,那么相应的组件就会运行不正常。使用这类组件的用户,应该不仅记录好你的表的基本结构,还要记录表的属性配置等,当发生修复运维行为的时候,主要再次核对确认。


​小结

    本文介绍了运维hbase基础原理中的数据完整性以及逆向元数据修复原理,并举例介绍两个逆向修复元数据的工具和实用执行步骤。后续会出系列文章,说明更多hbase运维基础、运作原理等,希望对大家的运维和使用HBase有所帮助。欢迎更多意见和HBase技术交流,钉钉扫码关注更多:

12c2eca00a159aa7f620847b3253568acb9c31d7

相关实践学习
lindorm多模间数据无缝流转
展现了Lindorm多模融合能力——用kafka API写入,无缝流转在各引擎内进行数据存储和计算的实验。
云数据库HBase版使用教程
  相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情: https://cn.aliyun.com/product/hbase   ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
2月前
|
机器学习/深度学习 人工智能 弹性计算
智能化运维:AI在故障预测与自我修复系统中的应用
随着技术的不断进步,传统的运维模式已逐渐不能满足现代企业的需求。本文将探讨如何通过人工智能技术,特别是机器学习和深度学习算法,实现对IT系统的实时监控、故障预测以及自动化修复。我们将分析AI技术在智能运维中的具体应用案例,并讨论其带来的效率提升和成本节约效果。文章旨在为读者提供一种全新的运维视角,展示AI技术在提高系统稳定性和减少人工干预方面的潜力。
|
2月前
|
机器学习/深度学习 运维 监控
智能化运维:机器学习在故障预测和自动化修复中的应用
随着信息技术的迅猛发展,企业对运维工作的效率和准确性要求越来越高。传统的运维模式已难以应对日益复杂的系统环境和数据量。本文将探讨如何利用机器学习技术提升运维工作的智能化水平,实现故障的早期预测和自动化修复,从而减少系统停机时间,提高企业运营效率。通过分析机器学习在运维领域的应用实例,揭示其在实际工作中的有效性和潜力。
49 0
|
3月前
|
机器学习/深度学习 人工智能 运维
智能化运维:AI在故障预测与自动化修复中的应用
【6月更文挑战第15天】本文探讨了人工智能(AI)技术在现代IT运维领域的革新性应用,重点分析了AI如何通过机器学习算法实现对系统故障的预测和自动化修复。文章首先概述了智能化运维的概念及其重要性,随后详细介绍了AI技术在故障检测、诊断和修复过程中的关键作用,并通过实际案例展示了AI运维解决方案的有效性。最后,文章讨论了实施智能化运维的挑战与未来发展趋势。
230 3
|
3月前
|
机器学习/深度学习 缓存 运维
智能化运维:机器学习在故障预测与自动修复中的应用
随着信息技术的飞速发展,企业系统日益复杂,传统运维模式面临巨大挑战。智能化运维作为一种新兴趋势,通过集成机器学习算法,实现对系统故障的预测和自动修复,显著提高运维效率与准确性。本文深入探讨了智能化运维的概念、关键技术及其在故障预测和自动修复方面的应用实例,旨在为读者提供一种科学严谨、数据导向的视角,理解智能化运维的价值与实践路径。
106 0
|
3月前
|
机器学习/深度学习 数据采集 运维
智能化运维:机器学习在故障预测与自动修复中的应用
随着技术的快速发展,智能化运维已成为提高系统稳定性和效率的关键。本文深入探讨了机器学习在故障预测和自动修复中的应用,分析了如何通过数据驱动的方法优化运维流程,并提出了实施智能化运维的策略。文章结合最新的研究成果和案例分析,为读者提供了一套完整的智能化运维解决方案。
141 0
|
3月前
|
存储 SQL 分布式计算
技术心得记录:深入学习HBase架构原理
技术心得记录:深入学习HBase架构原理
|
4月前
|
机器学习/深度学习 人工智能 运维
智能化运维:基于AI的系统异常检测与自动修复策略
【5月更文挑战第29天】 在现代IT基础设施管理领域,智能化运维正逐步成为推动效率和稳定性的关键因素。本文深入探讨了人工智能(AI)技术在系统异常检测和自动化故障修复中的应用,提出了一个集成的智能运维框架。该框架利用机器学习算法分析历史数据,实时监控关键性能指标,并在检测到潜在问题时触发自动化修复流程。通过这一方法,我们旨在降低人工干预的需求,提高系统的可靠性和业务连续性。
|
4月前
|
存储 算法 分布式数据库
HBase原理 | HBase内部探险
HBase原理 | HBase内部探险
109 0
|
10月前
|
存储 缓存 负载均衡
98 hbase原理
98 hbase原理
60 0
|
存储 运维 监控
分布式数据库HBase的重要机制和原理的宕机恢复和故障处理
HBase是一个分布式数据库系统,支持高可用性、高性能和高伸缩性。在分布式环境中,数据的分布式存储和管理是非常重要的。HBase通过分布式存储和管理数据来实现高可用性和高性能。同时,HBase还提供了一些重要的机制和原理来支持宕机恢复和故障处理。
417 1