HBase遷移過(guò)程遇到問(wèn)題以及解決方法

這篇文章主要介紹“HBase遷移過(guò)程遇到問(wèn)題以及解決方法”，在日常操作中，相信很多人在HBase遷移過(guò)程遇到問(wèn)題以及解決方法問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對大家解答”HBase遷移過(guò)程遇到問(wèn)題以及解決方法”的疑惑有所幫助！接下來(lái)，請跟著(zhù)小編一起來(lái)學(xué)習吧！

一.遷移過(guò)程遇到問(wèn)題以及解決

客戶(hù)HBase版本：Version 0.94.15
騰訊大數據套件HBase版本：Version 1.2.1
客戶(hù)私有云系統版本（測試）：tlinux1.2
遇到的問(wèn)題以及解決過(guò)程如下：

1.HBase運行異?，F象一（date和hwclock）

HBase運行偶發(fā)不正常，出現組件停止運行的情況，看日志有說(shuō)時(shí)間的差異等信息，但date查看完全一致，想到可能是硬件時(shí)間的差異問(wèn)題，通過(guò)hwclock看，確實(shí)差異很大，通過(guò)hwclock -w調整后基本恢復。后確認初始化腳本中只對騰訊云環(huán)境的機器做了硬件時(shí)間同步，目前已優(yōu)化。

2.HBase運行異?，F象二（hostname 和/etc/resolv.conf）

HBase再次運行不正常，出現組件停止運行的情況。通過(guò)日志看如下錯誤
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
通過(guò)hostname看所有機器hostname均為內網(wǎng)IP，猜想可能是網(wǎng)絡(luò )交互的時(shí)候查詢(xún)什么表導致出現的不一致，查看解析信息如下

[root@10 ~]# hostname
10.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里相關(guān)search信息，停掉nscd服務(wù)后，重啟HBase，再未出現這個(gè)錯誤，HBase運行完全正常。

3.需要支持snappy的發(fā)現與修復過(guò)程：

• 遷移表的過(guò)程中計劃使用官方的import/export工具進(jìn)行，第一步需要在目標集群建表，通過(guò)desc信息在目標集群建表完成后，list可看到表，通過(guò)scan查詢(xún)后，無(wú)法查詢(xún)內容，查日志有如下錯誤：
  org.apache.hadoop.HBase.DoNotRetryIOException: Compression algorithm 'snappy' previously failed test.
  通過(guò)google查詢(xún)需要HBase支持snappy壓縮算法，通過(guò)hadoop checknative發(fā)現集群默認確實(shí)不支持snappy算法（雖然安裝snappyrpm）

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

  
  

• 通過(guò)手動(dòng)建表的方法用以下desc信息建表后可以list查看到表信息。scan無(wú)法查看表內容，日志發(fā)現如下錯誤
  desc信息：

  COLUMN FAMILIES DESCRIPTION                                                                 
  {NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOR
  EVER', 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', TT
  L => '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即可，在測試集群通過(guò)該方法，HBase啟動(dòng)失敗

• 后確認tlinux1.2的hadoop集群上支持snappy的方法：即需要在特定系統編譯hadoop相關(guān)本地庫（native庫）替換hadoop當前的native庫，然后HBase的啟動(dòng)環(huán)境腳本增加hadoop主目錄即可

• 目前tlinux1.2下的hadoop的nativesnappy庫有現網(wǎng)使用，同時(shí)需要保證這個(gè)hadoop的庫可以引用到libjvm.so（jre的一個(gè)so文件）直接替換hadoop/lib下的native目錄，保證已經(jīng)安裝snappy的rpm包，在HBase-env.sh里添加HADOOP_HOME={Hadoop安裝主目錄}。再hadoop checknative后發(fā)現已支持snappy。逐步全量重啟HBase。

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

  
  

4.HBase0.9.4集群數據表到HBase1.2.1集群數據表的遷移方法

暴力遷移參考http://my.oschina.net/CainGao/blog/616502
1)找到源集群源表在hdfs上的目錄位置，直接將該目錄移動(dòng)到目標集群HBase的表在目標集群hdfs上的表根目錄下

2)暴力遷移時(shí)tableinfo信息是一個(gè)文件即.tableinfo.00000001。0.9.4的版本這個(gè)文件位于HBase表在hdfs上表目錄的根目錄下，而1.2.1的這個(gè)文件位于HBase表在hdfs上表目錄的根目錄下的./tabledesc目錄下，需要手動(dòng)創(chuàng )建這個(gè)目錄并調整這個(gè)文件的位置

3) 修改復制過(guò)來(lái)的表目錄文件的屬主信息

4) 重啟HBase的所有組件

5) 此時(shí)登錄HBaseshell已經(jīng)可以通過(guò)list查看到遷移過(guò)來(lái)的表，但scan等操作會(huì )失敗

6) 通過(guò)HBase hbck -fixMeta修復meta信息；HBase hbck -fixAssignments 修復分區。這兩個(gè)步驟的操作過(guò)程中注意觀(guān)察日志是否有異常，實(shí)踐中首次嘗試此方法有大量錯誤，發(fā)現錯誤內容為snappy相關(guān)，支持snappy后，查看表信息，表內容正常，隨機選取表內容對比也正常，可認為此種方法遷移成功。

7) 通過(guò)import/export的方法遷移時(shí)需要在目標集群手動(dòng)創(chuàng )建目標表，查看源集群的表結構如下：
import/export參考地址

COLUMN FAMILIES DESCRIPTION                                                                  {NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOR
EVER', 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', TT
L => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', ENCODE_ON_DISK => 'true'}

通過(guò)該desc信息創(chuàng )建新表時(shí)出現如下錯誤：
Unknown argument ignored for column family A: ENCODE_ON_DISK
手動(dòng)測試只要加這個(gè)參數ENCODE_ON_DISK去建表一定會(huì )出現這個(gè)錯誤，建表會(huì )成功，但表信息里沒(méi)有這個(gè)字段了。經(jīng)過(guò)look查代碼發(fā)現這個(gè)字段在新版本已經(jīng)廢棄，但客戶(hù)的老集群是版本需要這個(gè)字段，通過(guò)import的方法無(wú)法正常寫(xiě)入、通過(guò)步驟6）的暴力遷移成功后（暴力遷移成功兼容了這個(gè)字段），查看表的desc信息如下：

COLUMN FAMILIES DESCRIPTION                                                                  {NAME => 'A', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOR
EVER', 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', TT
L => '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 => 'FOR
EVER', 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', TT
L => 'FOREVER', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true', ENCODE_ON_DISK => 'true'}

可以看到關(guān)于ENCODE_ON_DISK字段在新老版本的定義方法有差異，故我們測試在新集群使用上面的desc信息建表后，再通過(guò)import方法導入到HBase。結果依然沒(méi)有數據寫(xiě)入，可以斷定這個(gè)參數ENCODE_ON_DISK在HBase1.2.1中完全廢棄，新版本采用了一個(gè)整字段來(lái)包裹這個(gè)信息。當老集群有參數時(shí)，官方import/export方法在HBase0.9.8到HBase1.2.1直接遷移暫時(shí)不可用。