Last write wins feature documentation

content/administrator-guide.ditamap

@@ -37,6 +37,7 @@
 		</topichead>
 	<topicref href="xdcr/xdcr-intro.dita">
 		<topicref href="xdcr/xdcr-create.dita"/>
+		<topicref href="xdcr/xdcr-monitor-timestamp-conflict-resolution.dita"/>
 		<topicref href="xdcr/xdcr-recover-partitions.dita"/>
 		<topicref href="xdcr/xdcr-tuning-performance.dita"/>
 		<topicref href="xdcr/xdcr-managing-security.dita"/>

content/architecture/high-availability-replication-architecture.dita

@@ -108,36 +108,21 @@
     identical topology. XDCR agents are topology aware and match the destination vBucket with the
     local vBucket, propagating mutations directly from vBucket to vBucket.</p>
    <p><b>Conflict Resolution in XDCR</b></p>
-   <p>When the same dataset is being mutated on both ends of an XDCR replication (source and
-    remote), then there is a high probability that conflicts could occur. XDCR automatically
-    performs conflict resolution for different document versions on source and destination
-    clusters.</p>
-   <p>The algorithm is designed to consistently select the same document on
-    either a source or destination cluster. For each stored document, XDCR perform checks of metadata to resolve conflicts. It checks the following:</p><ul>
-     <li><p>Revision ID, a numerical sequence that is incremented on each mutation</p></li>
-     <li><p>CAS value</p></li>
-     <li><p>Document flags</p></li>
-     <li><p>Expiration (TTL) value</p></li>
-    </ul>
-   <p>XDCR conflict resolution uses revision ID as the first field to resolve conflicts between two
-    writes across clusters. Revision IDs are maintained per key and are incremented with every
-    update to the key. Revision IDs keep track of number of mutations to a key, thus XDCR conflict
-    resolution can be best characterized as "the most updates wins".</p><p>If a document does not have the highest revision number, changes to this document will not be stored or replicated; instead the document with the highest score will take precedence on both clusters. Conflict resolution is automatic and does not require any manual correction or selection of documents.</p>
-   <p>By default XDCR fetches metadata once for every document that it replicates, before it
-    replicates the document to the destination cluster. XDCR fetches metadata on the source cluster
-    and looks at the number of revisions for a document. It compares this number with the number of
-    revisions on the destination cluster and the document with more revisions is considered the
-    ‘winner.’</p><p>If XDCR determines a document from a source cluster will win conflict resolution, it puts the
-    document into the replication queue. If the document will lose conflict resolution because it
-    has a lower number of mutations, XDCR will not put it into the replication queue. Once the
-    replicated document reaches the destination, conflict resolution will be performed again by the
-    remote cluster to ensure that the correct document 'wins'. This is to ensure that the correct
-    version of the document 'wins' even if the document on the remote cluster has changed since the
-    initial replication from the source cluster. If the document from the source cluster is still
-    the ‘winner’ it will be persisted onto disk at the destination. The destination cluster will
-    discard the document version with the lowest number of mutations.</p>
-   <p>The key point is that the number of document mutations is the main factor that determines whether XDCR keeps a document version or not. This means that the document that has the most recent mutation may not be necessarily the one that wins conflict resolution. If both documents have the same number of mutations, XDCR selects a winner based on other document metadata. Precisely determining which document is the most recently changed is often difficult in a distributed system. The algorithm Couchbase Server uses does ensure that each cluster can independently reach a consistent decision on which document wins.</p>
+   <p>One aspect of database replication that is unique to cross datacenter replication (XDCR) is
+    the need to prepare for and manage conflicts between the two databases. Conflict resolution is
+    not an issue for an active off site backup or standby cluster since updates happen in only one
+    cluster. However, replication of data with XDCR is asynchronous and does not preclude updates
+    from occurring on different sides of the cluster, which means conflicts can happen unless there
+    is external coordination over how data is updated.</p>
+   <p>Until Couchbase Server version 4.6, XDCR conflict resolution used the revision ID as the first
+    field to resolve conflicts between two writes across clusters. Revision IDs keep track of the
+    number of mutations to a document; this XDCR conflict resolution can be best characterized as
+    “the most updates wins”. Couchbase Server 4.6 introduces another strategy for conflict
+    resolution, <i>timestamp-based resolution</i>, where conflicts are resolved by comparing
+    timestamps of conflicting documents. This conflict resolution mode is also known as Last Write
+    Wins (LWW) and is best characterized as “the most recent update wins”. </p>
+   <p>See <xref href="../xdcr/xdcr-conflict-resolution.dita#topic_zfs_h5q_pq"/> for more
+    details.</p>
   </section>
  </conbody>
 </concept>
-

content/cli/cbcli/bucket-create.dita

@@ -66,6 +66,11 @@
               <entry><codeph>--enable-index-replica=[0|1]</codeph></entry>
               <entry>Enables a defined number of replicas (yes=1, no=0)..</entry>
             </row>
+            <row>
+              <entry><codeph>--enable-timestamps</codeph></entry>
+              <entry>Enables timestamps to be stored for all documents and is used by the
+                timestamp-based conflict resolution strategy.</entry>
+            </row>
             <row>
               <entry><codeph>--wait</codeph></entry>
               <entry>Wait for the creation of the bucket to be completed before returning.</entry>
@@ -78,23 +83,46 @@
     </section>
     <section>
       <title>Examples</title>
+      <p>To create a new dedicated port Couchbase bucket:
+        <codeblock>couchbase-cli bucket-create -c 192.168.0.1:8091 \
+       --bucket=test_bucket \
+       --bucket-type=couchbase \
+       --bucket-port=11222 \
+       --bucket-ramsize=200 \
+       --bucket-replica=1 \
+       --bucket-priority=high \
+       --bucket-eviction-policy=valueOnly \
+       --enable-timestamps \
+       -u Administrator -p password</codeblock></p>
 
       <p>To create a Couchbase bucket and wait for bucket ready:</p>
-      <codeblock>couchbase-cli bucket-create -c 192.168.0.1:8091 -u Administrator -p password \ 
---bucket=test_bucket --bucket-type=couchbase \ 
---bucket-ramsize=200 --bucket-replica=1 --wait</codeblock>
-      <p>To create a new sasl memcached bucket:</p>
-      <codeblock>couchbase-cli bucket-create -c 192.168.0.1:8091 -u Administrator -p password \ 
---bucket=test_bucket --bucket-type=memcached --bucket-password=password \ 
---bucket-ramsize=200 --enable-flush=1 --enable-index-replica=1</codeblock>
-      <p>To create a new couchbase bucket with a high priority:</p>
-      <codeblock>couchbase-cli bucket-create -c 192.168.0.1:8091 -u Administrator -p password \
---bucket=test_bucket --bucket-type=couchbase \ 
---bucket-ramsize=200 --bucket-replica=1 --bucket-priority=high   </codeblock>
-      <p>To create a new sasl bucket and set the eviction policy to <codeph>valueOnly</codeph>:</p>
-      <codeblock>couchbase-cli bucket-create -c 192.168.0.1:8091 -u Administrator -p password \ 
---bucket=test_bucket --bucket-password=password --bucket-ramsize=200 \
---bucket-eviction-policy=valueOnly --enable-flush=1</codeblock>
+      <codeblock>couchbase-cli bucket-create -c 192.168.0.1:8091 \
+       --bucket=test_bucket \
+       --bucket-type=couchbase \
+       --bucket-port=11222 \
+       --bucket-ramsize=200 \
+       --bucket-replica=1 \
+       --bucket-priority=low \
+       --wait \
+       -u Administrator -p password</codeblock>
+      <p>To create a new SASL memcached bucket:</p>
+      <codeblock>couchbase-cli bucket-create -c 192.168.0.1:8091 \
+       --bucket=test_bucket \
+       --bucket-type=memcached \
+       --bucket-password=password \
+       --bucket-ramsize=200 \
+       --bucket-eviction-policy=valueOnly \
+       --enable-flush=1 \
+       -u Administrator -p password</codeblock>
+      <p>To create a new Couchbase bucket with a high priority:</p>
+      <codeblock>couchbase-cli bucket-create -c 192.168.0.1:8091 \
+       --bucket=test_bucket \
+       --bucket-type=couchbase \
+       --bucket-port=11222 \
+       --bucket-ramsize=200 \
+       --bucket-replica=1 \
+       --bucket-priority=high \
+       -u Administrator -p password  </codeblock>
     </section>
   </refbody>
   <related-links>

content/clustersetup/create-bucket.dita

@@ -45,15 +45,27 @@
           href="../architecture/db-engine-architecture.dita#concept_b5n_bwn_vs/full-ejection"/>
         before changing this setting. </p>
       <p><image href="../admin/picts/bucket-full-ejection.png" id="image_rcx_pcs_zs" align="left"
-        width="600"/></p>
+        width="570"/></p>
     </section>
 
     <section><title>Access Control</title><p>Access Control is configured using the Couchbase Web
         Console and is set for two ports: Standard port and Dedicated port:</p><p><image
-          href="../images/admin-access-control.png" align="left" width="600"/></p>More details about
+          href="../images/admin-access-control.png" align="left" width="570"/></p>More details about
       standard and dedicated ports are provided in <xref
         href="../security/security-pw-auth.dita#topic_jzr_ct2_gv/standardport"/>.</section>
-
+    <section id="bucket-creation-conflict-resolution"><title>Conflict Resolution</title>
+      <p>The conflict resolution strategy is set on a per bucket basis. It is chosen during bucket creation and cannot be changed. The default conflict resolution setting is “Sequence number”.</p>
+ <p>Timestamp based conflict resolution is only available to buckets created using Couchbase Server
+        version 4.6 or higher. To use the timestamp-based conflict resolution strategy, you must set
+        the conflict resolution method to <userinput>Timestamp</userinput> during bucket creation.
+        You can also set this conflict resolution method using the CLI <xref
+          href="../cli/cbcli/bucket-create.dita#reference_llp_znv_sq"/> command, or the <xref
+          href="../rest-api/rest-bucket-create.dita#rest-bucket-create">REST API</xref>.</p>
+<p>Note that the conflict resolution method on both the source and destination buckets must be the same. You cannot replicate between buckets with different conflict resolution methods.</p>
+
+    </section>
+    <image placement="break" href="../admin/picts/bucket-create-conflict-resolution-setting.png"
+      width="570" id="image_ady_hfw_py"/>
 
 
     <section>
@@ -70,7 +82,7 @@
         in clusters from 5 to 10 data nodes and three replicas only in clusters with 10 or more data
         nodes. </p>
       <p><image href="../admin/picts/create-replicas.png" id="image_fyn_mnv_4v" align="left"
-          width="720"/></p>
+          width="570"/></p>
     </section>
     <section>
       <title>Disk I/O Optimization</title>
@@ -82,15 +94,15 @@
         buckets with different priorities exist in the cluster, there are internal server resources
         allocated for high and low priority buckets. </p>
       <p><image href="../admin/picts/bucket-disk-io.png" id="image_rlt_j2s_zs" align="left"
-          width="720"/></p>
+          width="570"/></p>
     </section>
     <section>
       <title>Auto-Compaction</title>
       <p>This setting allows you to override the cluster-wide auto-compaction settings for the
         specified bucket. </p>
       <p>For the most part, you should never need to use this setting. </p>
       <p><image href="../admin/picts/bucket-auto-compact.png" id="image_bkg_wfs_zs" align="left"
-          width="720"/></p>
+          width="570"/></p>
     </section>
     <section>
       <title>Flush</title>

content/introduction/whats-new.dita

@@ -15,14 +15,15 @@
       <dlentry>
         <dt>Cross Datacenter Replication with Timestamp-based Conflict Resolution</dt>
         <dd>This release introduces a new option to resolve conflicts with XDCR using timestamps.
-          With this option, conflicts are resolved by comparing timestamps of conflicting documents.
-          The timestamp-based conflict resolution provides a new option for applications which want
-          users to continue seeing the latest change or version, no matter when conflicts are
-          resolved in the background. Server set timestamp on every document combines the best of
-          logical and physical clocks and captures the causality relationship like logical clocks,
-          and enables easy identification of consistent snapshots in distributed systems. For more
-          information, see <xref
-            href="../xdcr/xdcr-timestamp-based-conflict-resolution.dita"/>.</dd>
+            With this option, conflicts are resolved by comparing timestamps of conflicting
+            documents. The timestamp-based conflict resolution provides a new option for
+            applications which want users to continue seeing the latest change or version, no matter
+            when conflicts are resolved in the background. Server set timestamp on every document
+            combines the best of logical and physical clocks and captures the causality relationship
+            like logical clocks, and enables easy identification of consistent snapshots in
+            distributed systems. For more information, see <xref
+              href="../xdcr/xdcr-conflict-resolution.dita#topic_zfs_h5q_pq/timestamp-based-conflict-resolution"
+              />.</dd>
       </dlentry>
       <!--<dlentry>
         <dt>Cross Datacenter Awareness</dt>

content/rest-api/rest-bucket-create.dita

@@ -195,6 +195,19 @@
   -d 'replicaNumber=2' \
   -d 'proxyPort=11215' \   
   http://10.5.2.54:8091/pools/default/buckets</codeblock>
+			<p>Curl request example to set conflict resolution type:</p>
+			<p>Set the parameter <parmname>conflictResolutionType</parmname> to <codeph>lww</codeph> during
+				bucket creation. For example, use the following command to create a bucket on the
+				source cluster:</p>
+			<codeblock>curl -X POST -u Administrator:asdasd http://&lt;ip_address&gt;:8091/pools/default/buckets 
+-d name=newBucketSource -d conflictResolutionType=lww 
+-d authType=sasl -d ramQuotaMB=4096 
+-d saslPassword=passw0rd -d bucketType=couchbase</codeblock>
+			<p>Use the following command to create a bucket on the destination cluster:
+				<codeblock>curl -X POST -u Administrator:asdasd http://&lt;ip_address&gt;:8091/pools/default/buckets 
+-d name=newBucketDestination -d conflictResolutionType=lww 
+-d authType=sasl -d ramQuotaMB=4096 
+-d saslPassword=passw0rd -d bucketType=couchbase</codeblock></p>
 			<p>Raw HTTP request example:</p>
 			<p>The parameters for configuring the bucket are provided as payload data. Each
 				parameter and value are provided as a key/value pair where each pair is separated by

content/server-architecture.ditamap

@@ -6,7 +6,9 @@
  <topicref href="architecture/architecture-intro.dita"/>
   <topicref href="architecture/terminology.dita"/>
   <topicref href="architecture/connectivity-architecture.dita"/>
-  <topicref href="architecture/high-availability-replication-architecture.dita"/>
+  <topicref href="architecture/high-availability-replication-architecture.dita">
+   <topicref href="xdcr/xdcr-conflict-resolution.dita"/>
+  </topicref>
   <topicref href="architecture/storage-architecture.dita"/>
   <topicref href="architecture/managed-caching-layer-architecture.dita"/>
   <topicref href="architecture/cluster-manager.dita"/>