千家信息网

HBase迁移过程遇到问题以及解决方法

发表于:2024-11-27 作者:千家信息网编辑
千家信息网最后更新 2024年11月27日,这篇文章主要介绍"HBase迁移过程遇到问题以及解决方法",在日常操作中,相信很多人在HBase迁移过程遇到问题以及解决方法问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答
千家信息网最后更新 2024年11月27日HBase迁移过程遇到问题以及解决方法

这篇文章主要介绍"HBase迁移过程遇到问题以及解决方法",在日常操作中,相信很多人在HBase迁移过程遇到问题以及解决方法问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答"HBase迁移过程遇到问题以及解决方法"的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

一.迁移过程遇到问题以及解决

客户HBase版本:Version 0.94.15
腾讯大数据套件HBase版本:Version 1.2.1
客户私有云系统版本(测试):tlinux1.2
遇到的问题以及解决过程如下:

1.HBase运行异常现象一(date和hwclock)

HBase运行偶发不正常,出现组件停止运行的情况,看日志有说时间的差异等信息,但date查看完全一致,想到可能是硬件时间的差异问题,通过hwclock看,确实差异很大,通过hwclock -w调整后基本恢复。后确认初始化脚本中只对腾讯云环境的机器做了硬件时间同步,目前已优化。

2.HBase运行异常现象二(hostname 和/etc/resolv.conf)

HBase再次运行不正常,出现组件停止运行的情况。通过日志看如下错误
ERROR [regionserver//10.0.0.106:16020] regionserver.HRegionServer: Master passed us a different hostname to use; was=10.0.0.106, but now=host-10-0-0-106.openstacklocal
通过hostname看所有机器hostname均为内网IP,猜想可能是网络交互的时候查询什么表导致出现的不一致,查看dns解析信息如下

[root@10 ~]# hostname10.0.0.106; generated by /sbin/dhclient-script#search openstacklocal 0.0.106#nameserver 10.0.0.2#nameserver 10.0.0.3

search openstacklocal的情况,猜测是虚拟机的异常行为,注释掉resolv.conf里相关search信息,停掉nscd服务后,重启HBase,再未出现这个错误,HBase运行完全正常。

3.需要支持snappy的发现与修复过程:
  • 迁移表的过程中计划使用官方的import/export工具进行,第一步需要在目标集群建表,通过desc信息在目标集群建表完成后,list可看到表,通过scan查询后,无法查询内容,查日志有如下错误:
    org.apache.hadoop.HBase.DoNotRetryIOException: Compression algorithm 'snappy' previously failed test.
    通过google查询需要HBase支持snappy压缩算法,通过hadoop checknative发现集群默认确实不支持snappy算法(虽然安装snappyrpm

    Native library checking:hadoop:  true /data/tbds-base/usr/hdp/2.2.0.0-2041/hadoop/lib/native/libhadoop.sozlib:    true /lib64/libz.so.1snappy:  falselz4:     true revision:99bzip2:   falseopenssl: false build does not support openssl.


  • 通过手动建表的方法用以下desc信息建表后可以list查看到表信息。scan无法查看表内容,日志发现如下错误
    desc信息:

    COLUMN FAMILIES DESCRIPTION                                                                 {NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', METADATA => {'ENCODE_ON_DISK' => 'true'}}                       {NAME => 'D', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '2147483647', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', ENCODE_ON_DISK => 'true'}


    错误信息:

    org.apache.hadoop.HBase.DoNotRetryIOException: java.lang.RuntimeException: native snappy library not available: this version of libhadoop was built without snappy support


  • 在HBase-site.xml增加属性HBase.regionserver.codecs value为snappy即可,在测试集群通过该方法,HBase启动失败

  • 后确认tlinux1.2的hadoop集群上支持snappy的方法:即需要在特定系统编译hadoop相关本地库(native库)替换hadoop当前的native库,然后HBase的启动环境脚本增加hadoop主目录即可

  • 目前tlinux1.2下的hadoop的nativesnappy库有现网使用,同时需要保证这个hadoop的库可以引用到libjvm.so(jre的一个so文件)直接替换hadoop/lib下的native目录,保证已经安装snappy的rpm包,在HBase-env.sh里添加HADOOP_HOME={Hadoop安装主目录}。再hadoop checknative后发现已支持snappy。逐步全量重启HBase。

    Native library checking:hadoop:  true /data/tbds-base/usr/hdp/2.2.0.0-2041/hadoop/lib/native/libhadoop.sozlib:    true /lib64/libz.so.1snappy:  true /usr/lib64/libsnappy.so.1lz4:     true revision:99bzip2:   falseopenssl: false build does not support openssl.


4.HBase0.9.4集群数据表到HBase1.2.1集群数据表的迁移方法

暴力迁移参考http://my.oschina.net/CainGao/blog/616502
1)找到源集群源表在hdfs上的目录位置,直接将该目录移动到目标集群HBase的表在目标集群hdfs上的表根目录下

2)暴力迁移时tableinfo信息是一个文件即.tableinfo.00000001。0.9.4的版本这个文件位于HBase表在hdfs上表目录的根目录下,而1.2.1的这个文件位于HBase表在hdfs上表目录的根目录下的./tabledesc目录下,需要手动创建这个目录并调整这个文件的位置

3) 修改复制过来的表目录文件的属主信息

4) 重启HBase的所有组件

5) 此时登录HBaseshell已经可以通过list查看到迁移过来的表,但scan等操作会失败

6) 通过HBase hbck -fixMeta修复meta信息;HBase hbck -fixAssignments 修复分区。这两个步骤的操作过程中注意观察日志是否有异常,实践中首次尝试此方法有大量错误,发现错误内容为snappy相关,支持snappy后,查看表信息,表内容正常,随机选取表内容对比也正常,可认为此种方法迁移成功。

7) 通过import/export的方法迁移时需要在目标集群手动创建目标表,查看源集群的表结构如下:
import/export参考地址

COLUMN FAMILIES DESCRIPTION                                                                  {NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', METADATA => {'ENCODE_ON_DISK' => 'true'}}                       {NAME => 'D', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '2147483647', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', ENCODE_ON_DISK => 'true'}

通过该desc信息创建新表时出现如下错误:
Unknown argument ignored for column family A: ENCODE_ON_DISK
手动测试只要加这个参数ENCODE_ON_DISK去建表一定会出现这个错误,建表会成功,但表信息里没有这个字段了。经过look查代码发现这个字段在新版本已经废弃,但客户的老集群是版本需要这个字段,通过import的方法无法正常写入、通过步骤6)的暴力迁移成功后(暴力迁移成功兼容了这个字段),查看表的desc信息如下:

COLUMN FAMILIES DESCRIPTION                                                                  {NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', METADATA => {'ENCODE_ON_DISK' => 'true'}}                       {NAME => 'D', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '2147483647', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', METADATA => {'ENCODE_ON_DISK' => 'true'}}

老集群表结构

COLUMN FAMILIES DESCRIPTION                                                                 {NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', METADATA => {'ENCODE_ON_DISK' => 'true'}}                       {NAME => 'D', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '2147483647', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', ENCODE_ON_DISK => 'true'}

可以看到关于ENCODE_ON_DISK字段在新老版本的定义方法有差异,故我们测试在新集群使用上面的desc信息建表后,再通过import方法导入到HBase。结果依然没有数据写入,可以断定这个参数ENCODE_ON_DISK在HBase1.2.1中完全废弃,新版本采用了一个整字段来包裹这个信息。当老集群有参数时,官方import/export方法在HBase0.9.8到HBase1.2.1直接迁移暂时不可用。

到此,关于"HBase迁移过程遇到问题以及解决方法"的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注网站,小编会继续努力为大家带来更多实用的文章!

信息 集群 方法 目录 过程 错误 问题 运行 字段 文件 版本 目标 支持 内容 日志 成功 差异 手动 数据 暴力 数据库的安全要保护哪些东西 数据库安全各自的含义是什么 生产安全数据库录入 数据库的安全性及管理 数据库安全策略包含哪些 海淀数据库安全审计系统 建立农村房屋安全信息数据库 易用的数据库客户端支持安全管理 连接数据库失败ssl安全错误 数据库的锁怎样保障安全 服务器业务地址和管理地址区别 沙迪克数据库怎么自定义 南宁软件开发助理待遇 用python写网络安全 打印机的rpc服务器是什么 北京易游博通网络技术文库 河北电力应急软件开发推广 国家统计局国家数据库指标 数据库维护绩效考核指标 北京移动互联网科技有限公司 服务器安全狗使用体会 2019年网络安全执法检查 云服务器的虚拟机登录管理 空间网络安全大学教案 数据库常见的性能问题 进销存软件开发计划 四川人工智能软件开发价钱是多少 单片机软件开发平台 服务器如何卸载安全狗 共建网络安全共享网络文明主题班会内容过程 北京移动互联网科技有限公司 sum 服务器 github+软件开发 java项目数据库连接 app网络安全培训 网络安全管理平台soc 苹果12如何跳过服务器安全设置 一个国家网络安全生态建设 网络安全 重于泰山 网络安全培训机构推荐北京
0