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'才有效。