1. 程式人生 > >HBase的replication原理及部署

HBase的replication原理及部署

建表 ted 以及 borde 有一個 AS amp 為我 數據字典

一、hbase replication原理

hbase 的復制方式是 master-push 方式,即主集群推的方式,主要是因為每個rs都有自己的WAL。 一個master集群可以復制給多個從集群,復制是異步的,運行集群分布在不同的地方,這也意味著從集群和主集群的數據不是完全一致的,它的目標就是最終一致性。

1. Replication 總體結構

我們直接引用社區的架構圖如下,主集群的hlog中記錄了所有針對table的變更(目前的ddl不同步),通過實時讀取hlog中的entry來解析變更的數據然後發送到從集群中去。

技術分享圖片

2. Replication 工作流程

技術分享圖片

3. Replication Zookeeper上的結構

示例圖如下(此圖主要目的為展示結構,圖中文字信息僅供參考,以下文解釋說明部分為準):

技術分享圖片

【解釋說明】

hbase復制的狀態都存儲在zookeeper中,默認情況下存儲到 /hbase/replication,這個目錄有三個子節點: peers znode、rs znode和state。peer 節點管理slave集群在zk上的配置;state節點記錄replication運行的狀態;rs 節點記錄著本集群rs中對應的hlog同步的信息,包括check point信息。(如果人為的刪除 /hbase/replication 節點,會造成復制丟失數據)

peers znode:

存儲在 zookeeper中/hbase/replication/peers 目錄下,這裏存儲了所有的replication peers,還有他們的狀態。peer的值是它的cluster的key,key包括了cluster的信息有: zookeeper,zookeeper port以及hbase在hdfs的目錄。

/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都有一個子節點,標示replication是否激活,這個節點沒有任何子節點,只有一個boolean值。

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

rs znode:

rs node包含了哪些WAL是需要復制的,包括:rs hostname,client port以及start code。

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

每一個rs znode包括一個WAL replication 隊列,

/hbase/replication/rs
  /hostname.example.org,6020,1234
    /1
    /2     
[說明] hostname.example.org的start code為1234的wal需要復制到peer 1和peer 2。
每一個隊列都有一個znode標示每一個WAL上次復制的位置,每次復制的時候都會更新這個值。
/hbase/replication/rs
  /hostname.example.org,6020,1234
    /1
      23522342.23422 [VALUE: 254]
      12340993.22342 [VALUE: 0]   

二、replication的配置部署

1. 準備

既然是集群間的備份那麽我們至少需要準備兩個HBase集群來進行試驗,並且需要滿足:

  • 集群間版本需要一致
  • 集群間服務器需要互通
  • 相關表及表結構在兩個集群上存在且相同

2.啟用replication步驟

1> HBase默認此特性是關閉的,需要在集群上(所有集群)進行設定並重啟集群,通過手動修改或ambari界面管理在hbase-site.xml配置文件中將hbase.replication參數設定為true。

【參考】

master集群配置文件

<property>
<name>hbase.replication</name>
<value>true</value>
<description> 打開replication功能</description>
</property>
<property>
<name>replication.source.nb.capacity</name>
<value>5000</value>
<description> 主集群每次像備集群發送的entry最大的個數,推薦5000.可根據集群規模做出適當調整,slave集群服務器如果較多,可適當增大</description>
</property>
<property>
<name>replication.source.size.capacity</name> 
<value>4194304</value> 
<description> 主集群每次像備集群發送的entry的包的最大值大小,不推薦過大</description>
</property>
<property>
<name>replication.source.ratio</name>
<value>1</value>
<description> 主集群裏使用slave服務器的百分比</description>
</property>
<property>
<name>hbase.regionserver.wal.enablecompression</name>
<value>false</value>
<description> 主集群關閉hlog的壓縮</description>
</property>
<property>
<name> replication.sleep.before.failover</name>
<value>5000</value>
<description> 主集群在regionserver當機後幾毫秒開始執行failover</description>
</property>

slave 集群配置文件

<property>
<name>hbase.replication</name>
<value>true</value>
<description> 打開replication功能</description>
</property>

2>在主/源集群上和從/目標集群上都新建表:

create ‘usertable‘, ‘family‘

3>在主集群上設定需要向哪個集群上replication數據

add_peer:增加一個slave集群,一旦add,那麽master集群就會向這個slave集群上replication那些在master集群上表列族制定了REPLICATION_SCOPE=>‘1‘的信息。
[Addpeer]   hbase> add_peer ‘1‘,"zk1,zk2,zk3:2182:/hbase-prod" (zk的地址,端口和Slave的zk address)
示例:add_peer ‘1‘,‘xufeng-1:2181:/hbase_backup‘  //重要
#set_peer_tableCFs ‘1‘,‘usertable‘

4>在主集群上打開表student的復制特性

disable ‘usertable‘
alter ‘usertable‘,{NAME => ‘family‘,REPLICATION_SCOPE => ‘1‘}    //重要
enable ‘usertable‘

5>測試replication功能

//上面配置好replication功能後,執行此三條命令會發現slave集群相應的跟著發生了相同變化
put ‘usertable‘,‘row1‘,‘family:info‘,‘zzzz‘
scan ‘usertable‘,{STARTROW=>‘row1‘,ENDROW=>‘row1‘}
delete ‘usertable‘,‘row1‘,‘family:info‘   

6>附:相關命令

shell環境為我們提供了很多方法去操作replication特性。

技術分享圖片

set_peer_tableCFs:重新設定想slave集群replication哪些表的哪些列族,只對列族REPLICATION_SCOPE=>‘1‘有效
show_peer_tableCFs:觀察某個slave集群上唄replication的表和列族信息
append_peer_tableCFs:與set_peer_tableCFs相比是增量設定,不會覆蓋原有信息。
remove_peer_tableCFs:與append_peer_tableCFs操作相反。

list_replicated_tables:列出在master集群上所有設定為REPLICATION_SCOPE=>‘1‘的信息
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_peers
 PEER_ID CLUSTER_KEY STATE TABLE_CFS
 1 xufeng-1:2181:/hbase_backup ENABLED 
1 row(s) in 0.0080 seconds

三、運維經驗及遇到的問題

  • replication不會根據實際插入的順序來進行,只保證和master集群最終一致性。
  • 所有對於replication的shell操作,只對列族為REPLICATION_SCOPE=>‘1‘才有效。
  • 如果寫入量較大,Slave 集群必須做好table 的region提前分配,防止寫入全部落入1臺服務器。
  • 暫停服務和重新服務期間的數據還是可以被同步到slave中的,而停止服務和啟動服務之間的數據不會被同步。也即同步是針對配置replication後復制的新數據,舊數據需要手動遷移
  • 主集群對於同步的數據大小和個數采用默認值較大,容易導致備集群內存被壓垮。建議配置減少每次同步數據的大小

replication.source.size.capacity4194304

replication.source.nb.capacity2000

  • replication目前無法保證region級別的同步順序性。需要在slave 集群需要打開KEEP_DELETED_CELLS=true,後續可以考慮在配置檢測到屬於slave集群就直接把這個值打開
  • stop_replication後再start_replication,如果當前寫的hlog沒有滾動,停止期間的日誌會被重新同步過去,類似的如果stop replication後進行了rollhlog操作(手動或重啟集群),重新startreplication,新寫入的數據不能被馬上動態同步過去,需要再rollhlog一次。
  • replication.source.ratio 默認值為0.1,這樣導致slave集群裏只有10%對外提供轉發服務,導致這一臺壓力過大,建議測試環境將此值改為1。
  • 目前replication 對於壓縮的hlog的wal entry 無法解析,導致無法同步配置壓縮hlog 集群的數據。這是有數據字典引起的,目前建議主集群中的配置hbase.regionserver.wal.enablecompression設false。
  • 不要長時間使得集群處於disable狀態,這樣hlog會不停的roll後在ZK上增加節點,最終使得zk節點過多不堪重負。

。。。。待修整完善

參考網址:

https://blog.csdn.net/shenliang1985/article/details/51420112(好)

https://www.cnblogs.com/ios123/p/6410986.html?utm_source=itdadao&utm_medium=referral

http://lib.csdn.net/article/hbase/43717

https://blog.csdn.net/baiyangfu_love/article/details/38682349

HBase的replication原理及部署