# 同步复制 ## 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' ```