Repository: hbase
Updated Branches:
  refs/heads/master d016338e4 -> 29c46c483


HBASE-15985 clarify promises about edits from replication in ref guide

Signed-off-by: Andrew Purtell <apurt...@apache.org>


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

Branch: refs/heads/master
Commit: 29c46c4834a3f96e9fca33cb16bc7f3748fcd60c
Parents: d016338
Author: Sean Busbey <bus...@apache.org>
Authored: Tue Jun 7 17:16:55 2016 -0500
Committer: Sean Busbey <bus...@apache.org>
Committed: Tue Jul 5 13:03:18 2016 -0500

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


http://git-wip-us.apache.org/repos/asf/hbase/blob/29c46c48/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 13449c1..6e84237 100644
--- a/src/main/asciidoc/_chapters/ops_mgt.adoc
+++ b/src/main/asciidoc/_chapters/ops_mgt.adoc
@@ -1320,6 +1320,14 @@ The master cluster relies on randomization to attempt to 
balance the stream of r
 It is expected that the slave cluster has storage capacity to hold the 
replicated data, as well as any data it is responsible for ingesting.
 If a slave cluster does run out of room, or is inaccessible for other reasons, 
it throws an error and the master retains the WAL and retries the replication 
at intervals.
 
+.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.
+
+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.
+====
+
 .Terminology Changes
 [NOTE]
 ====

Reply via email to