http://git-wip-us.apache.org/repos/asf/hbase-site/blob/6444c276/book.html ---------------------------------------------------------------------- diff --git a/book.html b/book.html index 8244382..28dbf41 100644 --- a/book.html +++ b/book.html @@ -19179,7 +19179,7 @@ using HBase Shell. For more details see <a href="#cp_loading">Loading Coprocesso </li> <li> <p>Call the coprocessor from your client-side code. HBase handles the coprocessor -trapsparently.</p> +transparently.</p> </li> </ol> </div> @@ -25160,6 +25160,24 @@ 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.</p> </div> +<div class="admonitionblock warning"> +<table> +<tr> +<td class="icon"> +<i class="fa icon-warning" title="Warning"></i> +</td> +<td class="content"> +<div class="title">Consistency Across Replicated Clusters</div> +<div class="paragraph"> +<p>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.</p> +</div> +<div class="paragraph"> +<p>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.</p> +</div> +</td> +</tr> +</table> +</div> <div class="admonitionblock note"> <table> <tr> @@ -33748,7 +33766,7 @@ The server will return cellblocks compressed using this same compressor as long <div id="footer"> <div id="footer-text"> Version 2.0.0-SNAPSHOT<br> -Last updated 2016-04-11 14:30:43 UTC +Last updated 2016-06-15 16:11:32 UTC </div> </div> </body>
http://git-wip-us.apache.org/repos/asf/hbase-site/blob/6444c276/bulk-loads.html ---------------------------------------------------------------------- diff --git a/bulk-loads.html b/bulk-loads.html index e7f5511..da2508c 100644 --- a/bulk-loads.html +++ b/bulk-loads.html @@ -7,7 +7,7 @@ <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> - <meta name="Date-Revision-yyyymmdd" content="20160627" /> + <meta name="Date-Revision-yyyymmdd" content="20160705" /> <meta http-equiv="Content-Language" content="en" /> <title>Apache HBase – Bulk Loads in Apache HBase (TM) @@ -305,7 +305,7 @@ under the License. --> <a href="http://www.apache.org/";>The Apache Software Foundation</a>. All rights reserved. - <li id="publishDate" class="pull-right">Last Published: 2016-06-27</li> + <li id="publishDate" class="pull-right">Last Published: 2016-07-05</li> </p> </div>
