集群建備份，它是master/slaves結(jié)構(gòu)式的備份，由master推送，這樣更容易跟蹤現(xiàn)在備份到哪里了，況且region server是都有自己的WAL 和HLog日志，它就像mysql的主從備份結(jié)構(gòu)一樣，只有一個日志來跟蹤。一個master集群可以向多個slave集群推送，收到推送的集群會覆蓋它本地的edits日志。

這個備份操作是異步的，這意味著，有時候他們的連接可能是斷開的，master的變化不會馬上反應(yīng)到slave當(dāng)中。備份個格式在設(shè)計上是和mysql的statement-based replication是一樣的，全部的WALEdits（多種來自Delete和Put的Cell單元）為了保持原子性，會一次性提交。

HLogs是region server備份的基礎(chǔ)，當(dāng)他們要進(jìn)行備份時必須保存在hdfs上，每個region server從它需要的最老的日志開始進(jìn)行備份，并且把當(dāng)前的指針保存在zookeeper當(dāng)中來簡化錯誤恢復(fù)，這個位置對于每一個slave 集群是不同的，但是對于同一個隊列的HLogs是相同的。

下面這個是設(shè)計的結(jié)構(gòu)圖：

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

1）當(dāng)客戶端通過api發(fā)送Put、Delete或者ICV到region server，這些KeyValue被轉(zhuǎn)換成WALEdit，這個過程會被replication檢測到，每一個設(shè)置了replication的列族，會把scope添加到edit的日志，然后追加到WAL中，并被應(yīng)用到MemStore中。

2）在另一個線程當(dāng)中，edit被從log當(dāng)中讀取來，并且只有可以備份的KeyValues（列族為scoped為GLOBAL的，并且不是catalog，catalog指的是.META. 和 -ROOT-）

3-1）這個edit然后被打上master群集的UUID，當(dāng)buffer寫滿的時候或者讀完文件，buffer會發(fā)到slave集群的隨機(jī)的一個region server同步的，收到他們的region server把edit分開，一個表一個buffer，當(dāng)所有的edits被讀完之后，每一個buffer會通過HTable來flush，edits里面的master集群的UUID被應(yīng)用到了備份節(jié)點，以此可以進(jìn)行循環(huán)備份。

4-1）回到master的region server上，當(dāng)前WAL的位移offset已經(jīng)被注冊到了zookeeper上面。

3-2）這里面，如果slave的region server沒有響應(yīng)，master的region server會停止等待，并且重試，如果目標(biāo)的region server還是不可用，它會重新選擇別的slave的region server去發(fā)送那些buffer。

同時WALs會被回滾，并且保存一個隊列在zookeeper當(dāng)中，那些被region server存檔的Logs會更新他們在復(fù)制線程中的內(nèi)存中的queue的地址。

4-2）當(dāng)目標(biāo)集群可用了，master的region server會復(fù)制積壓的日志。

下面是一些具體的操作：

假設(shè)zookeeper當(dāng)中的節(jié)點是/hbase/replication ,?它會有三個子節(jié)點。

/hbase/replication/state /hbase/replication/peers /hbase/replication/rs

The State znode

state節(jié)點是記錄是否可以進(jìn)行備份的，它里面記錄這個一個boolean值，true或者false，它是由hbase.replication決定的，同事它會在ReplicationZookeeper當(dāng)中緩存，它還會因為在shell中執(zhí)行了stop_replication而改變。

/hbase/replication/state [VALUE: true]

The Peers znode

這個節(jié)點下面記錄著所有需要備份的集群和他們當(dāng)前的備份狀態(tài)，如下：

/hbase/replication/peers/1 [Value: zk1.host.com,zk2.host.com,zk3.host.com:2181:/hbase]/2 [Value: zk5.host.com,zk6.host.com,zk7.host.com:2181:/hbase]peer的id是自己在add_peer時候，自己提供的，后面的value是slave集群所使用的zookeeper集群，最后是所在的znode的父節(jié)點。

在每一個peer節(jié)點的下面還有一個表示狀態(tài)的節(jié)點：

/hbase/replication/peers/1/peer-state [Value: ENABLED]/2/peer-state [Value: DISABLED]

The RS znode

rs的節(jié)點下面包括了復(fù)制的region server以及需求復(fù)制的HLog的隊列，看圖就知道啦！

第一層節(jié)點記錄著region server的機(jī)器名，端口號以及start code。

/hbase/replication/rs/hostname.example.org,6020,1234/hostname2.example.org,6020,2856

下一層是需求復(fù)制的HLog的隊列：

/hbase/replication/rs/hostname.example.org,6020,1234/1/2

隊列里面需要復(fù)制的HLog，值是已經(jīng)被復(fù)制的最新的位置position。

/hbase/replication/rs/hostname.example.org,6020,1234/123522342.23422 [VALUE: 254]12340993.22342 [VALUE: 0]過程是上述的過程，下面展開講一下具體的細(xì)節(jié)。

1）選擇哪個region server去復(fù)制

當(dāng)master節(jié)點準(zhǔn)備好備份之后，它首先要通過slave集群的zookeeper，然后查看他們的rs的節(jié)點下面有多少可用的rs，然后隨機(jī)選擇他們中的一部分，默認(rèn)是10%，如果有150個機(jī)器的話，會選擇15個機(jī)器去發(fā)送。這個時候是有一個watcher在監(jiān)視著slave集群的rs下面的變化，如果節(jié)點發(fā)生了變化，它會通知master節(jié)點的region server重發(fā)。

2）錯誤恢復(fù)，直接來個實際的例子

一個有3個region server集群正在和一個peer id為2的集群進(jìn)行備份，每個region server下面都有一個隊列

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

/hbase/replication/rs/1.1.1.1,60020,123456780/2/1.1.1.1,60020.1234 (Contains a position)1.1.1.1,60020.12651.1.1.2,60020,123456790/2/1.1.1.2,60020.1214 (Contains a position)1.1.1.2,60020.12481.1.1.2,60020.13121.1.1.3,60020, 123456630/2/1.1.1.3,60020.1280 (Contains a position)

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

/hbase/replication/rs/1.1.1.1,60020,123456780/2/1.1.1.1,60020.1234 (Contains a position)1.1.1.1,60020.12651.1.1.2,60020,123456790/lock2/1.1.1.2,60020.1214 (Contains a position)1.1.1.2,60020.12481.1.1.2,60020.13121.1.1.3,60020,123456630/2/1.1.1.3,60020.1280 (Contains a position)2-1.1.1.2,60020,123456790/1.1.1.2,60020.1214 (Contains a position)1.1.1.2,60020.12481.1.1.2,60020.1312然后1.1.1.3又自己倒騰了一會兒，假設(shè)它也掛了，最后的形態(tài)會是這樣

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

/hbase/replication/rs/1.1.1.1,60020,123456780/2/1.1.1.1,60020.1378 (Contains a position)2-1.1.1.3,60020,123456630/1.1.1.3,60020.1325 (Contains a position)1.1.1.3,60020.14012-1.1.1.2,60020,123456790-1.1.1.3,60020,123456630/1.1.1.2,60020.1312 (Contains a position)1.1.1.3,60020,123456630/lock2/1.1.1.3,60020.1325 (Contains a position)1.1.1.3,60020.14012-1.1.1.2,60020,123456790/1.1.1.2,60020.1312 (Contains a position)原理說完了，從下面說說進(jìn)行這個備份操作是哪些要求吧

（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不能相同

?要使用這個集群建備份的功能需要先進(jìn)行以下的設(shè)置：

1、修改hbase-site.xml文件

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

2、add_peer

輸入這個命令，查看它的具體用法，然后添加

3、修改表的REPLICATION_SCOPE

disable 'your_table' alter 'your_table', {NAME => 'family_name', REPLICATION_SCOPE => '1'} enable 'your_table'

4、list_peers 查看一下狀態(tài)

5、備份完成之后如何進(jìn)行數(shù)據(jù)校驗，VerifyReplication就是專門來處理這個校驗的。我們需要提供peer的id還有表名，verifyrep是它的簡稱，要用hadoop jar來運行。

集群之間備份的網(wǎng)址，說明他們是怎么工作的：

http://hbase.apache.org/replication.html

總結(jié)

以上是生活随笔為你收集整理的hbase 学习（十三）集群间备份原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。