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會複製積壓的日誌。

　　下面是一些具體的操做：

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

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

 

The State znode

　　state節點是記錄是否能夠進行備份的，它裏面記錄這個一個boolean值，true或者false，它是由hbase.replication決定的，同事它會在ReplicationZookeeper當中緩存，它還會由於在shell中執行了stop_replication而改變。

/hbase/replication/state [VALUE: true]

 

The Peers znode

　　這個節點下面記錄着全部須要備份的集羣和他們當前的備份狀態，以下：

/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的父節點。

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

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

 

The RS znode

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

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

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

 

　　下一層是需求複製的HLog的隊列

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

 

　　隊列裏面須要複製的HLog，值是已經被複制的最新的位置position

/hbase/replication/rs                    /hostname.example.org,6020,1234
                        /1
                            23522342.23422 [VALUE: 254]                            12340993.22342 [VALUE: 0]

 

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

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上的真實的文件名，「地址，端口.時間戳」

/hbase/replication/rs/                      1.1.1.1,60020,123456780/                          2/                              1.1.1.1,60020.1234  (Contains a position)                              1.1.1.1,60020.1265
                      1.1.1.2,60020,123456790/                          2/                              1.1.1.2,60020.1214  (Contains a position)                              1.1.1.2,60020.1248
                              1.1.1.2,60020.1312
                      1.1.1.3,60020,    123456630/                          2/                              1.1.1.3,60020.1280  (Contains a position)

 

　　如今讓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。

/hbase/replication/rs/                      1.1.1.1,60020,123456780/                          2/                              1.1.1.1,60020.1234  (Contains a position)                              1.1.1.1,60020.1265
                      1.1.1.2,60020,123456790/
                          lock                          2/                              1.1.1.2,60020.1214  (Contains a position)                              1.1.1.2,60020.1248
                              1.1.1.2,60020.1312
                      1.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.1248
                              1.1.1.2,60020.1312

 

　　而後1.1.1.3又本身倒騰了一下子，假設它也掛了，最後的形態會是這樣

　　1.1.1.1把1.1.1.3的未完成事業給接過了過來，因此咱們看到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.1401

                          2-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/
                          lock                          2/                              1.1.1.3,60020.1325  (Contains a position)                              1.1.1.3,60020.1401

                          2-1.1.1.2,60020,123456790/                              1.1.1.2,60020.1312  (Contains a position)

 

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

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

 

　　要使用這個集羣建備份的功能須要先進行如下的設置

一、修改hbase-site.xml文件

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

 

二、add_peer

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

三、修改表的REPLICATION_SCOPE

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

 

四、list_peers 查看一下狀態

五、備份完成以後如何進行數據校驗，VerifyReplication就是專門來處理這個校驗的。咱們須要提供peer的id還有表名，verifyrep是它的簡稱，要用hadoop jar來運行

集羣之間備份的網址，說明他們是怎麼工做的  

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