Hbase Replication 介绍
https://blog.csdn.net/teriy/article/details/7954203
現狀
? ? ?Hbase 的replication目前在業界使用并不多見，原因有很多方面，比如說HDFS目前已經有多份備份在某種程度上幫助HBASE底層數據的安全性，而且很多公司的集群規模比較小并且對數據重要程度并不是很高，比如一些日志系統或者是作為一個歷史數據的第二個倉庫，來分流大量的讀請求。這樣及時數據丟失了也可以在其他的地方（數據庫集群）中找回來。對于這樣的情況Replication的Slave集群變得可有可無，重要性根本得不到體現。故如果管理員把hbase只作為一個低安全級別和非重要業務的一個管理平臺，那么下面對于Replication集群的討論可以不用浪費時間來閱讀。目前阿里集團有相當重要的應用存在于Hbase之上，包括在線和非在線的應用。那么Hbase數據的安全性也顯得彌足重要。對于單集群的存在的問題通常來自以下幾個方面：
- 數據管理人員的失誤，不可逆的DDL操作。
- 底層HDFS文件BLOCK塊corruption
- 短時間過度的讀數據對集群造成的壓力，增加服務器應對這種情況比較浪費資源。
- 系統升級，維護，診斷問題會造成集群不可用時間增長。
- 雙寫的原子性難以保證
- 不可預計的一些原因。（如機房斷電，大規模硬件損壞，斷網等）
- 離線應用的MR計算對在線讀寫造成的較大的延遲影響
如果為以上問題擔憂的話，Replication構建主被集群則是一種很好的選擇，我們也在這方面的做了一些簡單的研究。下面簡單說下我們的使用中遇到的問題和采取的方法
?
常用的在線備份方案及其比較
對于數據中心的數據冗余的備份方案，目前從一致性，事務性，延遲，吞吐量，數據損失，Failover幾個角度來分析有一下幾種方案。
????????簡單備份模式通過定時不定時的Dump出集群數據保證數據的安全性，通常可以通過snapshot或設置時間戳來dump數據來實現這種方案，如果方案簡介，設計優雅可以做到對在線數據中心低干擾或無干擾的數據備份。但這種方案缺點也是顯而易見的，只是對時間點之前的數據安全性得到保障，如果發生突發事件會導致不可避免的整段時間的數據丟失，為很多人無法接受。
????????主從模式（Master-Slave）這種模式比起簡單的備份模式多了很多優點，可以通過最終一致性保證數據的一致，數據從主集群到備集群延時較低，異步寫入不會對主集群帶來性能壓力，基本不會產生多少性能的影響，突發事件來臨時數據丟失很少，并且主集群的事務在備集群也可以得以保證。一般通過構造較好的Log系統加上check Point來實現，可以實現讀寫分離，主集群可以擔當讀寫服務，但備集群一般只承擔讀服務。
????????主主模式?(Master-Master)原理總體類似于主從模式，不同的是2個集群可以互相承擔寫的分離，都可承擔讀寫服務。
????????2階段提交這種方案保證了強一致性和事務，服務器返回給客戶端成功則表明數據一定已經成功備份，不會造成任何數據丟失。每臺服務器都可承擔讀寫服務。但缺點是造成集群延遲較高，總體吞吐下降。
????????Paxos算法基于Paxos算法的實現的強一致性方案，同一客戶端連接的server能保證數據的一致性。缺點是實現復雜，集群延遲和吞吐隨著集群服務器增加而邊差。
我們可以通過下面的一個圖標來說明簡化一下上面各種模式的特點。
?
| ? | 備份 | 主從 | 主主 | 2PC | Paxos |
| 數據一致性 | 差 | 保證最終一致性 | ? | 強一致性 | ? |
| 事務 | 無 | 主集群保證 | 分別保證 | 主集群保證 | 主集群保證 |
| 延遲 | 低 | 低 | 低 | 高 | 高 |
| 吞吐量 | 高 | 高 | 高 | 低 | 低 |
| 數據丟失 | 大量 | 最近短暫時間丟失 | 最近短暫時間丟失 | 無丟失 | 無丟失 |
| 集群服務 | 無服務 | 主讀寫從只讀 | 讀寫 | 讀寫 | 讀寫 |
?
????????Hbase Replication主從模式通過指定備集群，將Hlog里面的數據異步發送到備集群，對主集群基本沒有性能影響，數據延時時間較短。主集群提供讀寫服務，備集群提供讀服務。如果主集群有故障，可以快速切換到備集群。回過頭來我們可以看看Hbase的備份狀況，Hbase可以同過離線備份和在線備份提供上述的簡單備份模式，主從和主主三種備份模式模式
????????Hbase?簡單備份模式如果表不在線比較好辦，可以通過copy table或者是distcp + add table來解決。如果表在線并且不能讓其下線，只有通過snapshot方案對online的table實施備份（關于snapshot原理我發另一篇文章來解釋）。
????????Hbase Replication主主模式2個集群互為主備，都提供讀寫服務，讀寫分離。
通過比較，總體看來hbaseReplication的解決方案可以很好的解決集群安全性，數據安全性，讀寫分離，運維和客戶操作失誤等等的問題，并且易于管理和配置，為在線應用提供強有力的支持
原理
Replication 總體結構
Replication的總體架構比較簡單，我們直接引用社區的架構圖來說明，主集群的hlog中記錄了所有針對table的變更（目前的ddl不同步），通過實時讀取hlog中的entry來解析變更的數據然后發送到從集群中去。
?
Replication 工作流程
?
Replication Class 簡介
ReplicationSourceManager：Master的replication線程主要管理者，負責初始化，啟動或結束線程，同時也會watch主集群的ZK上RS節點在有RS退出或加入是時立即failover，保證數據的無丟失。
ReplicationZooKeeper :?用于控制和管理replication在Zookeeper上的一系列操作。
ReplicatioSource：replication工作線程，負責讀取，解析，發送和記錄Hlog
ReplicationLogCleanner：管理Replication時的hlog
ReplicationSink:?備集群用于接收主集群的hlog entry后，分析并寫入本集群
NodeFailover：處理節點退出后為處理完的hlog.
ZKWatcher：watch replication對應的zk節點，并啟動對應的任務。
?
Replication Zookeeper上的結構
?
Peer?節點：管理slave集群在zk上的配置。
State節點：記錄replication運行的狀態
Rs?節點：記錄著本集群Rs中對應的hlog同步的信息，包括check point信息
Replication Failover
Hbase Replication?在replication時，我們通常會遇到主集群和備集群的RS預料之中或者預料之外的上線下線。在發生這種情況的時候，必須設計出一種穩定合理的并且有迭代功能的Failover處理機制來保證數據不會丟失。我們可以分別分析主從集群遇到這種情況時Failover的處理方案。
?
?
- ??主集群RS加入?:zk會迅速watch到rs節點的創建，創建出新的replication source線程來處理新加入到hlog.
- ??主集群RS退出：這是最為復雜的一種情況，主要是退出的RS會有一部分的hlog沒有處理完，需要穩定的shift到其他RS上，我們可以從下面三個步驟說明。
- ?集群正常工作時，ZK的狀態如下：
?
這是1.1.1.2這臺RS突然下線，ZK會第一時間watch到這個動作，最先發現的集群中的某臺（1.1.1.3）rs將其在Replication/rs下對應的lock住，并將其考到自己的節點之下。其他的RS（1.1.1.1）發現其被lock后就不做動作。
1.1.1.3啟動一個新的線程處理掉所有未被同步的hlog.保證數據不丟失。同理如果1.1.1.3此時再次下線，zk節點被迭代拷貝
?
?
- ??備集群RS加入:不影響主集群的步驟，region均勻的話客戶端會自動寫入到新加入到集群之中。
- ??備集群RS退出：主集群在重試幾次后發現對方down機，將其加入到deadserver的列表之中，后續不會被Call
?
部署?
Hbase的部署詳細步驟如下
?Master 集群配置文件
?
?
?Slave 集群配置文件
?
Master 集群配置
?
?
- ??修改好Master集群配置文件
- ? 關聯replication Master 和 Slave 集群，在 master hbase shell 中做以下操作 <下面的操作可以在master集群未啟動時完成>
- ? ? [Addpeer]?? hbase> add_peer '1',"zk1,zk2,zk3:2182:/hbase-prod" (zk 的地址，端口，和Slave的zk address)
- ? ? ? Start replication 標志??hbase> start_replication （add peer 和 start replication 標記是直接修改zk 上的node,所以不需要啟動集群做這個動作）
?
?
Slave集群配置
?
?
- ? 修改好Slave集群配置文件，并啟動slave集群
- ? 根據需要在Slave中創建需要同步的table,注意每個CF的KEEP_DELETED_CELLS => 'true’屬性要打開來保證為寫入的順序性。
b) 重新服務：
hbase> enable_peer '1'
c) 停止服務
hbase> stop_replication
?
?
?
?
做好上述2個集群配置后 啟動Master集群，將需要同步的table 的replication scope打開。
其他一些操作：
a) 暫停服務：
暫停服務和重新服務期間的數據還是可以被同步到slave中的，而停止服務和啟動服務之間的數據不會被同步。
運維經驗及遇到的問題
?
?
- ? 如果寫入量較大，Slave 集群必須做好table 的region提前分配，防止寫入全部落入1臺服務器。
- ? 暫停服務和重新服務期間的數據還是可以被同步到slave中的，而停止服務和啟動服務之間的數據不會被同步。
- ? 主集群對于同步的數據大小和個數采用默認值較大，容易導致備集群內存被壓垮。建議配置減少每次同步數據的大小
- 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節點過多不堪重負。
- ? 如何初始化slave集群數據？目前我們開發了hlogrestore工具，可以distcp主集群數據或snapshot主集群數據后，將數據導入備集群，最后追上主集群的數據后開啟replication.
- ?Master Push數據的方式會不會影響master的性能。基本不會，我們還開發出了一個slave拉數據的版本，根據一下測試結果我們發現，相差都不大。理由是master只是單線程順序讀hdfs上的文件并發送，消耗很低。
?
從主集群結果看，壓力從20線程到200線程，兩種replication都沒對TPS和RT造成太大影響，CPUload也沒有太大變化，在網絡流量上會有一定的增長.
轉載于:https://www.cnblogs.com/davidwang456/articles/9253672.html
總結
以上是生活随笔為你收集整理的Hbase Replication 介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HBase最佳实践
- 下一篇： 优酷蓝鲸近千节点的Redis集群运维经验