hbase 學習（十三）叢集間備份原理

叢集建備份，它是master/slaves結構式的備份，由master推送，這樣更容易跟蹤現在備份到哪裡了，況且region server是都有自己的wal 和hlog日志，它就像mysql的主從備份結構一樣，隻有一個日志來跟蹤。一個master叢集可以向多個slave叢集推送，收到推送的叢集會覆寫它本地的edits日志。

這個備份操作是異步的，這意味着，有時候他們的連接配接可能是斷開的，master的變化不會馬上反應到slave當中。備份個格式在設計上是和mysql的statement-based replication是一樣的，全部的waledits（多種來自delete和put的cell單元）為了保持原子性，會一次性送出。

hlogs是region server備份的基礎，當他們要進行備份時必須儲存在hdfs上，每個region server從它需要的最老的日志開始進行備份，并且把目前的指針儲存在zookeeper當中來簡化錯誤恢複，這個位置對于每一個slave 叢集是不同的，但是對于同一個隊列的hlogs是相同的。

下面這個是設計的結構圖：

下面我們了解一下master和一個slave節點的整個過程。

1）當用戶端通過api發送put、delete或者icv到region server，這些keyvalue被轉換成waledit，這個過程會被replication檢測到，每一個設定了replication的列族，會把scope添加到edit的日志，然後追加到wal中，并被應用到memstore中。

2）在另一個線程當中，edit被從log當中讀取來，并且隻有可以備份的keyvalues（列族為scoped為global的，并且不是catalog，catalog指的是.meta. 和 -root-）

3-1）這個edit然後被打上master群集的uuid，當buffer寫滿的時候或者讀完檔案，buffer會發到slave叢集的随機的一個region server同步的，收到他們的region server把edit分開，一個表一個buffer，當所有的edits被讀完之後，每一個buffer會通過htable來flush，edits裡面的master叢集的uuid被應用到了備份節點，以此可以進行循環備份。

4-1）回到master的region server上，目前wal的位移offset已經被注冊到了zookeeper上面。

3-2）這裡面，如果slave的region server沒有響應，master的region server會停止等待，并且重試，如果目标的region server還是不可用，它會重新選擇别的slave的region server去發送那些buffer。

同時wals會被復原，并且儲存一個隊列在zookeeper當中，那些被region server存檔的logs會更新他們在複制線程中的記憶體中的queue的位址。

4-2）當目标叢集可用了，master的region server會複制積壓的日志。

<b>下面是一些具體的操作：</b>

假設zookeeper當中的節點是/hbase/replication , 它會有三個子節點。

state節點是記錄是否可以進行備份的，它裡面記錄這個一個boolean值，true或者false，它是由hbase.replication決定的，同僚它會在replicationzookeeper當中緩存，它還會因為在shell中執行了stop_replication而改變。

這個節點下面記錄着所有需要備份的叢集和他們目前的備份狀态，如下：

peer的id是自己在add_peer時候，自己提供的，後面的value是slave叢集所使用的zookeeper叢集，最後是所在的znode的父節點。

在每一個peer節點的下面還有一個表示狀态的節點：

rs的節點下面包括了複制的region server以及需求複制的hlog的隊列，看圖就知道啦！

第一層節點記錄着region server的機器名，端口号以及start code。

下一層是需求複制的hlog的隊列：

隊列裡面需要複制的hlog，值是已經被複制的最新的位置position。

過程是上述的過程，下面展開講一下具體的細節。

1）選擇哪個region server去複制

當master節點準備好備份之後，它首先要通過slave叢集的zookeeper，然後檢視他們的rs的節點下面有多少可用的rs，然後随機選擇他們中的一部分，預設是10%，如果有150個機器的話，會選擇15個機器去發送。這個時候是有一個watcher在監視着slave叢集的rs下面的變化，如果節點發生了變化，它會通知master節點的region server重發。

2）錯誤恢複，直接來個實際的例子

一個有3個region server叢集正在和一個peer id為2的叢集進行備份，每個region server下面都有一個隊列

隊列中的每個znode都是hdfs上的真實的檔案名，“位址，端口.時間戳”。

現在讓1.1.1.2的zookeeper丢失session，觀察者會建立一個lock，這個時候1.1.1.3完成了，它會把1.1.1.2的給接手過來，在自己的znode下面建立一個新的znode，并且加上dead的server的名稱，就像下面這樣子，原來的1.1.1.2的下面多了一層lock，1.1.1.3下面多了一個，和它原始的狀态也不一樣，前面多了個2。

然後1.1.1.3又自己倒騰了一會兒，假設它也挂了，最後的形态會是這樣

1.1.1.1把1.1.1.3的未完成事業給接過了過來，是以我們看到1.1.1.1下面有個三手貨和幾個二手貨。。。

原理說完了，從下面說說進行這個備份操作是哪些要求吧

（1）hbase的大的版本要一緻

0.90.1 可以向0.90.0推送但是0.90.1不可以向0.89.20100725推送

（2）獨立部署的zookeeper叢集

（3）叢集間的備份的表名和列族都要一緻

（4）多個slave叢集的話，要0.92以上版本

（5）叢集間可以互相通路

（6）叢集間的zookeeper.znode.parent不能相同

<b> 要使用這個叢集建備份的功能需要先進行以下的設定：</b>

1、修改hbase-site.xml檔案

2、add_peer

輸入這個指令，檢視它的具體用法，然後添加

3、修改表的replication_scope

4、list_peers 檢視一下狀态

5、備份完成之後如何進行資料校驗，verifyreplication就是專門來處理這個校驗的。我們需要提供peer的id還有表名，verifyrep是它的簡稱，要用hadoop jar來運作。

叢集之間備份的網址，說明他們是怎麼工作的：

<a href="http://hbase.apache.org/replication.html">http://hbase.apache.org/replication.html</a>

<a href="http://images.cnitblog.com/blog/477362/201405/021733142059772.png"></a>