[How to]HBase集羣備份方法--Replication機制

1.簡介

　　HBase備份的方法在[How to]HBase集羣備份方法文章中已經有些介紹，可是這些方法都不是HBase自己的特性在支持，都是經過MR計算框架結合HBase客戶端的方式，或者直接拷貝HBase的底層hdfs數據的方式進行備份的，但從操做上來講也比較繁瑣複雜，數據完整性和及時性上也作的並非很好。

　　本文介紹另一種集羣間的數據自動備份特性，這個特性是HBase的內部特性，用戶數據備份和數據容災和集羣功能劃分。

　　數據容災能夠認爲只是爲了數據的保存的措施，除此以外咱們也能夠靈活使用這種機制一般其可以適用於以下場景：

• 數據備份和容災恢復

• 數據歸集

• 數據地理分佈

• 在線數據服務和線下數據分析

2.前準備

　　既然是集羣間的備份那麼咱們至少須要準備兩個HBase集羣來進行試驗，準備以下HBase集羣。在測試環境上準備有兩套HBase集羣，資源有限緣由他們共享一個hdfs集羣和zookeeper，經過配置不一樣node路徑和hdfs上數據路徑來區別開。

　　　　

　　　　

　　其中xufeng-3做爲源集羣，xufeng-1做爲目標集羣

1.集羣間版本須要一致
2.集羣間服務器須要互通
3.相關表及表結構在兩個集羣上存在且相同 

3.啓用Replication步驟

　　1. HBase默認此特性是關閉的，須要在集羣上（全部集羣）進行設定並重啓集羣，將hbase.replication參數設定爲true

  <property>
    <name>hbase.replication</name>
    <value>true</value>
  </property>

 

　　2.在源集羣上和目標集羣上都新建表：

hbase(main):006:0> create 'replication_source_table','f1','f2'
0 row(s) in 0.3920 seconds

=> Hbase::Table - replication_source_table

　　3.在源集羣的表上標註出須要備份的列族信息，以下將進行對於f1列族下數據的replication

hbase(main):008:0> alter 'replication_source_table',{NAME=>'f1', REPLICATION_SCOPE=>'1'}
Updating all regions with the new schema...
0/1 regions updated.
1/1 regions updated.
Done.
0 row(s) in 2.2830 seconds

　　4.如今設定須要向那個集羣上replication數據，在hbase shell中執行命令。下面的命令指明瞭目標集羣的zookeeper地址，以及它在這個zookeeper上路徑，有了這些信息

　　至關於就知道了整個目標集羣的信息。

hbase(main):010:0> add_peer '1',"xufeng-1:2181:/hbase_backup"
0 row(s) in 0.1220 seconds

 

　　5.經過shell命令能夠看到目標集羣已經被 添加到了源集羣的replication中。

hbase(main):013:0> list_peers
 PEER_ID CLUSTER_KEY STATE TABLE_CFS
 1 xufeng-1:2181:/hbase_backup ENABLED 
1 row(s) in 0.0450 seconds

 

　　6.如今咱們在步驟3上被做爲replication的表上進行數據的插入

hbase(main):005:0> scan 'replication_source_table'
ROW                     COLUMN+CELL                                                       
 row1                   column=f1:a, timestamp=1469939791335, value=f1-a                  
 row2                   column=f1:b, timestamp=1469939801684, value=f1-b                  
 row3                   column=f2:a, timestamp=1469939814071, value=f2-a                  
 row4                   column=f2:b, timestamp=1469939821430, value=f2-b                  
4 row(s) in 0.0610 seconds

　　7.查看xufeng-1的目標集羣上的同名的表上是否有數據產生？

hbase(main):007:0> scan 'replication_source_table'
ROW                     COLUMN+CELL                                                      
 row1                   column=f1:a, timestamp=1469939791335, value=f1-a                 
 row2                   column=f1:b, timestamp=1469939801684, value=f1-b                 
2 row(s) in 0.0340 seconds

hbase(main):008:0> 

　　能夠看到源集羣表上的f1列族下的數據都被replication到了目標集羣的對應表中。（f2列族並無設定replication的scope，因此不會被賦值）

　　8.進一步的咱們在源集羣表上刪除一行row1行這個數據：

hbase(main):009:0> delete 'replication_source_table','row1','f1:a'
0 row(s) in 0.0200 seconds

　　查看對應的目標集羣表數據，數據一樣被刪除

hbase(main):009:0> scan 'replication_source_table'
ROW                     COLUMN+CELL                                                      
 row2                   column=f1:b, timestamp=1469939801684, value=f1-b                 
1 row(s) in 0.0230 seconds

 

　　9.若是要中止對於某個集羣的replication，能夠執行disable_peer，一樣的要想再次開啓可以使用enable_peer，更多關於使用方法可在hbase shell中的help中查看：

  Group name: replication
  Commands: add_peer, append_peer_tableCFs, disable_peer, enable_peer, list_peers, list_replicated_tables, remove_peer, remove_peer_tableCFs, set_peer_tableCFs, show_peer_tableCF 

4.replication應用場景

　　數據容災能夠認爲只是爲了數據的保存的措施，除此以外咱們也能夠靈活使用這種機制一般其可以適用於以下場景：

• 數據備份和容災恢復

• 數據歸集

• 數據地理分佈

• 在線數據服務和線下數據分析

　　多個集羣間的互相備份能夠造成集羣間的拓撲結構：以下不一樣地域間的集羣合一將數據放置到某個中心備份集羣上，中心備份集羣會將須要作分析的數據同步到數據分析集羣，通過數據分析後將結果同步到其餘業務集羣上。

　　　　　　　　　　　　　　

5.Replication原理

　　5.1 概要：

　　Replication是使用協處理器的Endpoint來實現的，基本原理是將源集羣的regionserver會將WAL日誌按順序讀取，並將WAL日誌讀取日誌offset等信息經過zookeeper記錄，讀取以後主動的想目標集羣的regionserver發送這些信息，在目標集羣的regionserver接收到信息後會使用HTable客戶端將這些信息插入的對應的表中。源集羣的regionserver是endpoint的客戶端，目標集羣上的regionserver有endpoint的服務端實現，二者經過protobuf協議實現RPC通訊，基於這一點因此須要集羣間的版本一致，網絡互通。

官方上給出的原理圖以下：

　　　　　　　　　　　　　　　　　

　　對於Replication機制來講他是經過Endpint來時實現的，這一點從其源代碼上既能看出：

　　　　　　　　　　　　　　　

　　對於其原理上來講官方的說明圖並不清晰，這裏我本身畫了一個嘗試去解釋：

　　　　　　　　　　　　　　

　　對於源集羣上的Regionserver來講其自身就是Endpoint的客戶端，她經過讀取本身所持有的hlog日誌（當其餘機器死掉時候也會接管其餘regionserver的hlog日誌）而後同步調用rpc機制去向遠端目標集羣上的regionserver發送信息並等待相應，目標集羣上並非全部的regionserver都參與到接受信息的活動中，源集羣會經過zookeeper來watch到目標集羣上的全部rs信息而後根據比例（可配）的服務器個數來參與到replication中。目標集羣上的regionserver的endpoint服務端接受到這些信息就會經過普通的htable客戶端API進行數據的put，最後會返回結果給源集羣的調用者，調用者會記錄下hlog日誌的offset信息保存。而後繼續讀取和發送。因此整體而言replication須要hlog做爲數據源，解析hlog發送到遠端regionserver，遠端regionserver經過api將數據插入到對應表中去。

　　對於以上分爲兩部分，一部分是源集羣是如何運行的，目標集羣上是如何相應的來解釋。

 

5.2 Replication機制

　　zookeeper節點介紹：

　　對於目標集羣或者說slave集羣來講，他是服務端，被動的接受來自客戶端也就是源集羣或者說master集羣的請求，接受到請求後再包裝成操做進行API的調用將數據插入到自身集羣。

從這一點來看，主要工做都是master集羣來完成的，前面也介紹replication機制是經過讀取hlog來記性數據重建的。而且經過zookeeper來記錄當前replication的進度，因此咱們先看一下在zookeeper中是如何定義Replication的：

　　　　　　　　　　　　

從上圖能夠看到/peers中記錄着master集羣要向哪些slave集羣進行replication，而且知道某個slave集羣上須要replication哪些表的那些列族信息。

/rs中節點記錄着當前master集羣的全部regionserver信息，每個regionserver中又記錄着這個regionserver上須要向哪些slave集羣replication信息，而且知道向某個salve集羣上那些hlog須要被replication，和當前某個hlog被replication的進度信息。

　　master集羣regionserver的宕機處理：

　　master集羣的每個regionserver都會負責其所持有的hlog日誌，可是當某臺宕機以後會作什麼處理呢？

　　

　　1. master集羣上的regionserver都會經過zookeeper來相互watch。

　　2.當某臺宕機後，其餘rs會去其節點下搶注lock節點，如上圖，1.1.1.2宕機，1.1.1.3註冊到了lock節點，他會將1.1.1.2的信息賦值到其幾點下，1.1.1.2的節點信息將會以peer_id-1.1.1.2rs信息爲節點被寫入1.1.1.3節點下，他會開啓一個新線程去處理1.1.1.2的hlog信息。

　　3.可是若是1.1.1.3也宕機了，那麼1.1.1.1最爲最後的rs將會寫入lock節點，而後按照一樣的方式去處理。

　　

　　master集羣rs上hlog歸檔機制：

　　hlog會被RS進行歸檔，也就是說hlog的路徑會被修改，當歸檔後，記錄在zookeeper上的hlog節點信息會更新其路徑，通常的：

　　1.當這個hlog文件尚未被replication被讀取，那麼會更新路徑。

　　2.當hlog正在被replication讀取中，則不會更新路徑信息，由於hlog路徑的改變只是一個namenode上邏輯信息的改變，既然已經在讀取了，去塊分佈式不會被修改的。

　　3.只要master集羣開啓的replication機制，而且add了peer，那麼即便這個peer是disable，hlog都不會被刪除，而是須要等待replication對這些hlog讀取完畢後才能被刪除。

 

5.3 shell命令詳解：

　　shell環境咱們提供了不少方法去操做replication特性：

  Group name: replication
  Commands: add_peer, append_peer_tableCFs, disable_peer, enable_peer, list_peers, list_replicated_tables, remove_peer, remove_peer_tableCFs, set_peer_tableCFs, show_peer_tableCFs

 

add_peer:增長一個slave集羣,一旦add那麼master集羣就會向這個slave集羣上replication那些在master集羣上表列族制定了REPLICATION_SCOPE=>'1'的信息。

add_peer '1','xufeng-1:2181:/hbase_backup'

 

list_peers：顯示當前master集羣一共向哪些集羣進行replication

hbase(main):009:0> list_peers
 PEER_ID CLUSTER_KEY STATE TABLE_CFS
 1 xufeng-1:2181:/hbase_backup ENABLED 1 row(s) in 0.0110 seconds

disable_peer:中止向某個slave集羣進行replication

hbase(main):010:0> disable_peer '1'
0 row(s) in 0.0110 seconds

hbase(main):011:0> list_peers
 PEER_ID CLUSTER_KEY STATE TABLE_CFS
 1 xufeng-1:2181:/hbase_backup DISABLED 1 row(s) in 0.0070 seconds

 

enable_peer:與disable_peer意義相反

hbase(main):031:0> enable_peer '1'
0 row(s) in 0.0070 seconds

hbase(main):032:0> list
list                     list_labels              list_namespace
list_namespace_tables    list_peers               list_quotas
list_replicated_tables   list_snapshots
hbase(main):032:0> list_peers
 PEER_ID CLUSTER_KEY STATE TABLE_CFS
 1 xufeng-1:2181:/hbase_backup ENABLED 
1 row(s) in 0.0080 seconds

 

set_peer_tableCFs：重寫設定想slave集羣replication哪些表的哪些列族，只對列族REPLICATION_SCOPE=>'1'有效

append_peer_tableCFs：與set_peer_tableCFs相比是增量設定，不會覆蓋原有信息。

remove_peer_tableCFs：與append_peer_tableCFs操做相反。

list_replicated_tables：列出在master集羣上全部設定爲REPLICATION_SCOPE=>'1'的信息

hbase(main):065:0> list_replicated_tables
TABLE:COLUMNFAMILY           ReplicationType                                         
 replication_source_table:f1 GLOBAL                                                  
 replication_source_table:f2 GLOBAL                                                  
 replication_test_table:f1   GLOBAL                                                  
3 row(s) in 0.0190 seconds

show_peer_tableCFs：觀察某個slave集羣上唄replication的表和列族信息

hbase(main):066:0> show_peer_tableCFs '1'
replication_source_table:f1;replication_test_table:f1

5.4 注意點
　　1. 當replicaion不成功的時候回形成hlog日誌積壓。即便當前replication都disable狀態。
　　2. replication不會根據實際插入的順序來進行，只保證和master集羣最終一致性。
　　3. 全部對於replication的shell操做，只對列族爲REPLICATION_SCOPE=>'1'纔有效。