src/main/asciidoc/_chapters/sync_replication.adoc

   1 ////
   2 /**
   3  *
   4  * Licensed to the Apache Software Foundation (ASF) under one
   5  * or more contributor license agreements.  See the NOTICE file
   6  * distributed with this work for additional information
   7  * regarding copyright ownership.  The ASF licenses this file
   8  * to you under the Apache License, Version 2.0 (the
   9  * "License"); you may not use this file except in compliance
  10  * with the License.  You may obtain a copy of the License at
  11  *
  12  *     http://www.apache.org/licenses/LICENSE-2.0
  13  *
  14  * Unless required by applicable law or agreed to in writing, software
  15  * distributed under the License is distributed on an "AS IS" BASIS,
  16  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  17  * See the License for the specific language governing permissions and
  18  * limitations under the License.
  19  */
  20 ////
  21
  22 [[syncreplication]]
  23 = Synchronous Replication
  24 :doctype: book
  25 :numbered:
  26 :toc: left
  27 :icons: font
  28 :experimental:
  29 :source-language: java
  30
  31 == Background
  32
  33 The current <<Cluster Replication, replication>> in HBase in asynchronous. So if the master cluster crashes, the slave cluster may not have the
  34 newest data. If users want strong consistency then they can not switch to the slave cluster.
  35
  36 == Design
  37
  38 Please see the design doc on link:https://issues.apache.org/jira/browse/HBASE-19064[HBASE-19064]
  39
  40 == Operation and maintenance
  41
  42 Case.1 Setup two synchronous replication clusters::
  43
  44 * Add a synchronous peer in both source cluster and peer cluster.
  45
  46 For source cluster:
  47 [source,ruby]
  48 ----
  49 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"=>[]}
  50 ----
  51
  52 For peer cluster:
  53 [source,ruby]
  54 ----
  55 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"=>[]}
  56 ----
  57
  58 NOTE: For synchronous replication, the current implementation require that we have the same peer id for both source
  59 and peer cluster. Another thing that need attention is: the peer does not support cluster-level, namespace-level, or
  60 cf-level replication, only support table-level replication now.
  61
  62 * Transit the peer cluster to be STANDBY state
  63
  64 [source,ruby]
  65 ----
  66 hbase> transit_peer_sync_replication_state '1', 'STANDBY'
  67 ----
  68
  69 * Transit the source cluster to be ACTIVE state
  70
  71 [source,ruby]
  72 ----
  73 hbase> transit_peer_sync_replication_state '1', 'ACTIVE'
  74 ----
  75
  76 Now, the synchronous replication has been set up successfully. the HBase client can only request to source cluster, if
  77 request to peer cluster, the peer cluster which is STANDBY state now will reject the read/write requests.
  78
  79 Case.2 How to operate when standby cluster crashed::
  80
  81 If the standby cluster has been crashed, it will fail to write remote WAL for the active cluster. So we need to transit
  82 the source cluster to DOWNGRANDE_ACTIVE state, which means source cluster won't write any remote WAL any more, but
  83 the normal replication (asynchronous Replication) can still work fine, it queue the newly written WALs, but the
  84 replication block until the peer cluster come back.
  85
  86 [source,ruby]
  87 ----
  88 hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE'
  89 ----
  90
  91 Once the peer cluster come back, we can just transit the source cluster to ACTIVE, to ensure that the replication will be
  92 synchronous.
  93
  94 [source,ruby]
  95 ----
  96 hbase> transit_peer_sync_replication_state '1', 'ACTIVE'
  97 ----
  98
  99 Case.3 How to operate when active cluster crashed::
 100
 101 If the active cluster has been crashed (it may be not reachable now), so let's just transit the standby cluster to
 102 DOWNGRADE_ACTIVE state, and after that, we should redirect all the requests from client to the DOWNGRADE_ACTIVE cluster.
 103
 104 [source,ruby]
 105 ----
 106 hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE'
 107 ----
 108
 109 If the crashed cluster come back again, we just need to transit it to STANDBY directly. Otherwise if you transit the
 110 cluster to DOWNGRADE_ACTIVE, the original ACTIVE cluster may have redundant data compared to the current ACTIVE
 111 cluster. Because we designed to write source cluster WALs and remote cluster WALs concurrently, so it's possible that
 112 the source cluster WALs has more data than the remote cluster, which result in data inconsistency. The procedure of
 113 transiting ACTIVE to STANDBY has no problem, because we'll skip to replay the original WALs.
 114
 115 [source,ruby]
 116 ----
 117 hbase> transit_peer_sync_replication_state '1', 'STANDBY'
 118 ----
 119
 120 After that, we can promote the DOWNGRADE_ACTIVE cluster to ACTIVE now, to ensure that the replication will be synchronous.
 121
 122 [source,ruby]
 123 ----
 124 hbase> transit_peer_sync_replication_state '1', 'ACTIVE'
 125 ----