HBase迁移过程遇到问题以及解决方法
这篇文章主要介绍“HBase迁移过程遇到问题以及解决方法”,在日常操作中,相信很多人在HBase迁移过程遇到问题以及解决方法问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”HBase迁移过程遇到问题以及解决方法”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
一.迁移过程遇到问题以及解决
客户HBase版本:Version 0.94.15
腾讯大数据套件HBase版本:Version 1.2.1
客户私有云系统版本(测试):tlinux1.2
10年积累的成都网站设计、网站建设、外贸网站建设经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先网站设计后付款的网站建设流程,更有江油免费网站建设让你可以放心的选择与我们合作。
遇到的问题以及解决过程如下: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
[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.
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无法查看表内容,日志发现如下错误
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的方法迁移时需要在目标集群手动创建目标表,查看源集群的表结构如下:
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
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迁移过程遇到问题以及解决方法
网站URL:http://cdiso.cn/article/eghpod.html