Repository: hbase
Updated Branches:
  refs/heads/branch-2 469b57bba -> 1f674e2b2


HBASE-17918 document serial replication

Signed-off-by: zhangduo <zhang...@apache.org>


Project: http://git-wip-us.apache.org/repos/asf/hbase/repo
Commit: http://git-wip-us.apache.org/repos/asf/hbase/commit/1f674e2b
Tree: http://git-wip-us.apache.org/repos/asf/hbase/tree/1f674e2b
Diff: http://git-wip-us.apache.org/repos/asf/hbase/diff/1f674e2b

Branch: refs/heads/branch-2
Commit: 1f674e2b20dda81f9bc7f012a00eeec3cf96c7a7
Parents: 469b57b
Author: meiyi <me...@xiaomi.com>
Authored: Mon Apr 9 20:57:18 2018 +0800
Committer: zhangduo <zhang...@apache.org>
Committed: Tue Apr 10 09:44:41 2018 +0800

----------------------------------------------------------------------
 src/main/asciidoc/_chapters/ops_mgt.adoc | 34 ++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/hbase/blob/1f674e2b/src/main/asciidoc/_chapters/ops_mgt.adoc
----------------------------------------------------------------------
diff --git a/src/main/asciidoc/_chapters/ops_mgt.adoc 
b/src/main/asciidoc/_chapters/ops_mgt.adoc
index b4e2ad2..b303d19 100644
--- a/src/main/asciidoc/_chapters/ops_mgt.adoc
+++ b/src/main/asciidoc/_chapters/ops_mgt.adoc
@@ -1400,9 +1400,12 @@ If a slave cluster does run out of room, or is 
inaccessible for other reasons, i
 .Consistency Across Replicated Clusters
 [WARNING]
 ====
-How your application builds on top of the HBase API matters when replication 
is in play. HBase's replication system provides at-least-once delivery of 
client edits for an enabled column family to each configured destination 
cluster. In the event of failure to reach a given destination, the replication 
system will retry sending edits in a way that might repeat a given message. 
Further more, there is not a guaranteed order of delivery for client edits. In 
the event of a RegionServer failing, recovery of the replication queue happens 
independent of recovery of the individual regions that server was previously 
handling. This means that it is possible for the not-yet-replicated edits to be 
serviced by a RegionServer that is currently slower to replicate than the one 
that handles edits from after the failure.
+How your application builds on top of the HBase API matters when replication 
is in play. HBase's replication system provides at-least-once delivery of 
client edits for an enabled column family to each configured destination 
cluster. In the event of failure to reach a given destination, the replication 
system will retry sending edits in a way that might repeat a given message. 
HBase provides two ways of replication, one is the original replication and the 
other is serial replication. In the previous way of replication, there is not a 
guaranteed order of delivery for client edits. In the event of a RegionServer 
failing, recovery of the replication queue happens independent of recovery of 
the individual regions that server was previously handling. This means that it 
is possible for the not-yet-replicated edits to be serviced by a RegionServer 
that is currently slower to replicate than the one that handles edits from 
after the failure.
 
 The combination of these two properties (at-least-once delivery and the lack 
of message ordering) means that some destination clusters may end up in a 
different state if your application makes use of operations that are not 
idempotent, e.g. Increments.
+
+To solve the problem, HBase now supports serial replication, which sends edits 
to destination cluster as the order of requests from client. See <<Serial 
Replication,Serial Replication>>.
+
 ====
 
 .Terminology Changes
@@ -1443,6 +1446,9 @@ Instead of SQL statements, entire WALEdits (consisting of 
multiple cell inserts
 LOG.info("Replicating "+clusterId + " -> " + peerClusterId);
 ----
 
+.Serial Replication Configuration
+See <<Serial Replication,Serial Replication>>
+
 .Cluster Management Commands
 add_peer <ID> <CLUSTER_KEY>::
   Adds a replication relationship between two clusters. +
@@ -1464,6 +1470,32 @@ enable_table_replication <TABLE_NAME>::
 disable_table_replication <TABLE_NAME>::
   Disable the table replication switch for all its column families.
 
+=== Serial Replication
+
+Note: this feature is introduced in HBase 2.1
+
+.Function of serial replication
+
+Serial replication supports to push logs to the destination cluster in the 
same order as logs reach to the source cluster.
+
+.Why need serial replication?
+In replication of HBase, we push mutations to destination cluster by reading 
WAL in each region server. We have a queue for WAL files so we can read them in 
order of creation time. However, when region-move or RS failure occurs in 
source cluster, the hlog entries that are not pushed before region-move or 
RS-failure will be pushed by original RS(for region move) or another RS which 
takes over the remained hlog of dead RS(for RS failure), and the new entries 
for the same region(s) will be pushed by the RS which now serves the region(s), 
but they push the hlog entries of a same region concurrently without 
coordination.
+
+This treatment can possibly lead to data inconsistency between source and 
destination clusters:
+
+1. there are put and then delete written to source cluster.
+
+2. due to region-move / RS-failure, they are pushed by different 
replication-source threads to peer cluster.
+
+3. if delete is pushed to peer cluster before put, and flush and major-compact 
occurs in peer cluster before put is pushed to peer cluster, the delete is 
collected and the put remains in peer cluster, but in source cluster the put is 
masked by the delete, hence data inconsistency between source and destination 
clusters.
+
+
+.Serial replication configuration
+
+. Set the serial flag to true for a repliation peer. You can either set it to 
true when creating a replication peer, or change it to true later.
+
+The serial replication feature had been done firstly in 
link:https://issues.apache.org/jira/browse/HBASE-9465[HBASE-9465] and then 
reverted and redone in 
link:https://issues.apache.org/jira/browse/HBASE-20046[HBASE-20046]. You can 
find more details in these issues.
+
 === Verifying Replicated Data
 
 The `VerifyReplication` MapReduce job, which is included in HBase, performs a 
systematic comparison of replicated data between two different clusters. Run 
the VerifyReplication job on the master cluster, supplying it with the peer ID 
and table name to use for validation. You can limit the verification further by 
specifying a time range or specific families. The job's short name is 
`verifyrep`. To run the job, use a command like the following:

Reply via email to