# 同步復制 ## 93\. 背景 HBase中當前的[復制](#_cluster_replication)是異步的。因此，如果主集群崩潰，則從集群可能沒有最新數據。如果用戶想要強一致性，那么他們就無法切換到從屬集群。 ## 94\. 設計 請參閱 [HBASE-19064](https://issues.apache.org/jira/browse/HBASE-19064) 上的設計文檔 ## 95\. 運行和維護 Case.1 設置兩個同步復制集群 * 在源集群和對等集群中添加同步對等體。 對于源群集: ``` hbase> add_peer '1', CLUSTER_KEY => 'lg-hadoop-tst-st01.bj:10010,lg-hadoop-tst-st02.bj:10010,lg-hadoop-tst-st03.bj:10010:/hbase/test-hbase-slave', REMOTE_WAL_DIR=>'hdfs://lg-hadoop-tst-st01.bj:20100/hbase/test-hbase-slave/remoteWALs', TABLE_CFS => {"ycsb-test"=>[]} ``` 對于對等集群: ``` hbase> add_peer '1', CLUSTER_KEY => 'lg-hadoop-tst-st01.bj:10010,lg-hadoop-tst-st02.bj:10010,lg-hadoop-tst-st03.bj:10010:/hbase/test-hbase', REMOTE_WAL_DIR=>'hdfs://lg-hadoop-tst-st01.bj:20100/hbase/test-hbase/remoteWALs', TABLE_CFS => {"ycsb-test"=>[]} ``` > 對于同步復制，當前實現要求源和對等集群具有相同的對等ID。另一件需要注意的事情是：peer不支持集群級，命名空間級或cf-level復制，現在只支持表級復制。 * 將對等集群轉換為STANDBY狀態 ``` hbase> transit_peer_sync_replication_state '1', 'STANDBY' ``` * 將源群集轉換為ACTIVE狀態 ``` hbase> transit_peer_sync_replication_state '1', 'ACTIVE' ``` 現在，已成功設置同步復制。 HBase客戶端只能請求源集群，如果請求到對等集群，現在處于STANDBY狀態的對等集群將拒絕讀/寫請求。 Case.2 備用集群崩潰時的操作方法 如果備用群集已崩潰，則無法為活動群集寫入遠程WAL。因此我們需要將源集群轉移為DOWNGRANDE_ACTIVE狀態，這意味著源集群將不再同步任何遠程WAL，但正常復制（異步復制）仍然可以正常工作，它會對新寫入的WAL進行排隊，但復制會阻塞直到對等集群恢復。 ``` hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE' ``` 一旦對等集群恢復，我們就可以將源集群轉移為ACTIVE，以確保復制是同步的。 ``` hbase> transit_peer_sync_replication_state '1', 'ACTIVE' ``` Case.3 當活動集群崩潰時如何操作 如果活動集群已崩潰（現在可能無法訪問），那么我們需要將備用集群轉移為DOWNGRANDE_ACTIVE狀態，之后，將客戶端的所有請求重定向到DOWNGRADE_ACTIVE集群。 ``` hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE' ``` 如果崩潰的集群再次恢復，我們只需要將其直接轉移為STANDBY狀態。否則，如果將集群轉移為DOWNGRADE_ACTIVE狀態，則原始ACTIVE集群可能具有比當前ACTIVE集群更多的冗余數據。因為我們的設計是會將源集群WAL和遠程集群WAL一起寫，所以源集群WALs可能比遠程集群具有更多數據，這會導致數據不一致。將ACTIVE轉換為STANDBY狀態是沒有問題的，因為我們將跳過重放原始的WAL。 ``` hbase> transit_peer_sync_replication_state '1', 'STANDBY' ``` 之后，我們可以將DOWNGRADE_ACTIVE集群提升為ACTIVE，以確保復制是同步的。 ``` hbase> transit_peer_sync_replication_state '1', 'ACTIVE' ```