DOC-12484 XDCR Conflict Logging feature

modules/ROOT/nav.adoc

@@ -82,6 +82,10 @@ include::third-party:partial$nav.adoc[]
     **** xref:learn:clusters-and-availability/xdcr-filtering.adoc[XDCR Advanced Filtering]
     **** xref:learn:clusters-and-availability/xdcr-conflict-resolution.adoc[XDCR Conflict Resolution]
     **** xref:learn:clusters-and-availability/xdcr-with-scopes-and-collections.adoc[XDCR with Scopes and Collections]
+    **** xref:learn:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc[XDCR enableCrossClusterVersioning]
+    **** xref:learn:clusters-and-availability/xdcr-conflict-logging-feature.adoc[XDCR Conflict Logging]
+      ***** xref:learn:clusters-and-availability/xdcr-viewing-conflict-logs.adoc[Viewing Conflict Logs]
+    **** xref:learn:clusters-and-availability/xdcr-active-active-sgw.adoc[XDCR Active-Active with Sync Gateway]
   *** xref:learn:clusters-and-availability/groups.adoc[Server Group Awareness]
 * xref:learn:security/security-overview.adoc[Security]
  ** xref:learn:security/authentication.adoc[Authentication]

modules/introduction/partials/new-features-80.adoc

@@ -113,6 +113,11 @@ Additional information sent by clients at connection time can be found in the lo
 https://jira.issues.couchbase.com/browse/MB-61048[MB-61048]::
 Once faulty remote cluster credentials are fixed, XDCR will now be able to more quickly restart replications that depend on the repaired references.
 
+https://jira.issues.couchbase.com/browse/MB-58989[MB-58989]::
+XDCR detects and logs concurrent conflicts that occur in different clusters but on the same document version due to independent modifications by locally connected applications during Active-Active replication.
+The conflict logs are for your information only.
+For more information, see xref:learn:clusters-and-availability/xdcr-conflict-logging-feature.adoc[XDCR Conflict Logging Feature].
+
 [#section-new-feature-800-query-service]
 === Query Service
 

modules/learn/pages/clusters-and-availability/xdcr-active-active-sgw.adoc

@@ -0,0 +1,99 @@
+= XDCR Active-Active with Sync Gateway
+:description: pass:q[You can use XDCR with Sync Gateway mobile clusters in a bi-directional, active-active replication, but you must make sure that both the Server and the Sync Gateway versions support this option. Otherwise, using XDCR with Sync Gateway buckets in a bi-directional replication can cause data corruption.]
+
+[abstract]
+{description}
+
+[#xdcr-active-active-sgw-intro]
+== Introduction
+
+NOTE: *To set up XDCR bi-directional replication with Sync Gateway (SGW), you need to have at least a Server 7.6.6 version and SGW 4.0.0 version.
+However, Sync Gateway 4.0.0 is a future release version.
+
+In the versions earlier than Server 7.6.6 and Sync Gateway (SGW) 4.0.0*, only an active-passive setup was supported with both XDCR and SGW.
+XDCR Active-Active replication with Sync Gateway for XDCR-Mobile interoperability configuration was introduced in the Server 7.6.6 version, where you can configure an active-active XDCR setup with Sync Gateway (SGW) and mobile applications both on the XDCR source and target clusters.
+
+[IMPORTANT] 
+====
+Here are a few limitations to the _XDCR Active-Active with Sync Gateway_ feature.
+
+* If you use the _user created extended attributes (user xattrs)_ in your documents, and you have more than 10 user xattrs in a document, then you cannot use the feature _XDCR Active-Active with Sync Gateway_.
+This is due to an internal limitation of managing extended attributes in a document.
+If you try to use the feature _XDCR Active-Active with Sync Gateway_ when you have more than 10 user xattrs in your document, the XDCR replication **silently skips** replicating that document.
+As a result, the data in the replication-skipped document will not be consistent between the target and source clusters.
+The only way you will know this skip occured is because the Prometheus stat `subdoc_cmd_docs_skipped` will be incremented and the document will _not_ be consistent between the target and source.
+* If you use Eventing service functions that update documents in XDCR-replicated buckets (Eventing source bucket mutations), ensure your functions do not cause continuous replication loops.
+In bi-directional active-active XDCR environments, Eventing functions that trigger document updates can lead to "ping-pong" replication unless you implement logic to prevent infinite loops.
+Always add safeguards to avoid redundant updates and unwanted replication behavior in bi-directional setups. For more information, see xref:sync-gateway:xdcr-active-active-eventing.adoc[XDCR Active-Active and Eventing].
+====
+
+You can configure XDCR Active-Active with Sync Gateway for XDCR-Mobile interoperability using one of the following methods:
+
+* xref:learn:clusters-and-availability/xdcr-active-active-sgw.adoc#xdcr-active-active-sgw-greenfield-deployment[Greenfield deployment]: Set up a new active-active configuration with both XDCR and SGW.
+* xref:learn:clusters-and-availability/xdcr-active-active-sgw.adoc#xdcr-active-active-sgw-upgrade[Upgrading an existing setup]: Convert an existing active-passive XDCR-SGW configuration to an active-active XDCR-SGW setup.
+
+NOTE: When using the feature _XDCR Active-Active with Sync Gateway_, where Sync Gateway version is 4.0* or a later version and Server is 7.6.6 or a later version, the replication target XDCR inbound user must have the RBAC roles, xref:learn:security/roles.adoc#xdcr-inbound[XDCR Inbound] role and xref:learn:security/roles.adoc#data-writer[Data Writer] role.
+
+[#xdcr-active-active-sgw-prerequisites]
+== Prerequisites
+
+Set the bucket property `enableCrossClusterVersioning` to use the setting `mobile=Active` during the processes xref:manage:manage-xdcr/create-xdcr-replication.adoc[Create a Replication] in xref:manage:manage-xdcr/xdcr-management-overview.adoc[Manage XDCR].
+To enable the bucket property `enableCrossClusterVersioning` using the REST API, see xref:learn:clusters-and-availability/xdcr-enable-crossclusterversioning.adoc#modify-enablecrossclusterversioning[Modify the bucket property enableCrossClusterVersioning] or xref:rest-api:rest-bucket-create.adoc#example-enablecrossclusterversioning-edit[Example: Turning on enableCrossClusterVersioning, when Editing].
+
+[#xdcr-active-active-sgw-greenfield-deployment]
+== Greenfield Deployment
+
+To configure a new active-active XDCR with Sync Gateway setup, do the following:
+
+. Create two clusters on Server 7.6.6 or a later version with _all_ the nodes of the clusters. For example, cluster A and cluster B (or you can upgrade the existing Server clusters to 7.6.6 or a later version).
+. Create buckets, for example, B1 and B2 in cluster A and cluster B respectively, between which XDCR will be set up. Now, do the following:
+.. Enable the ECCV setting on B1. All the mutations in B1 will have a new metadata called HLV.
+.. Enable the ECCV setting on B2. All the mutations in B2 will have a new metadata called HLV.
++
+NOTE: ECCV refers to the bucket property `enableCrossClusterVersioning`. If there are more than two buckets in the replication topology, you must enable ECCV for all those buckets.
++
+. Create an XDCR from B1 to B2 by setting `mobile=Active`. Also, create an XDCR from B2 to B1 by setting `mobile=Active`.
++
+For information about creating an XDCR by setting `mobile=Active` through the REST API, see xref:rest-api:rest-xdcr-create-replication.adoc[Creating a Replication].
++
+For information about creating an XDCR by setting `mobile=Active` from the UI, see xref:manage:manage-xdcr/create-xdcr-replication.adoc#create-an-xdcr-replication-with-the-ui[Create an XDCR Replication with the UI].
+. Configure SGW 4.0.0* version on each cluster, cluster A and cluster B. 
+
+This setup can handle application traffic on both buckets B1 and B2 of the respective clusters along with SGW import into both the buckets simultaneously.
+
+[#xdcr-active-active-sgw-upgrade]
+== Upgrading an existing setup
+
+You can convert an existing active-passive XDCR-Sync Gateway (SGW) setup into an active-active XDCR-Sync Gateway setup.
+
+For illustration, there are two clusters, A and B. An SGW is connected to cluster A and this cluster is active.
+Cluster B is passive with XDCR setup from bucket B1 in cluster A to bucket B2 in cluster B.
+The current application traffic should be only on bucket B1 of cluster A.
+
+.Replication before upgrade: XDCR Active-Passive with SGW
+image::clusters-and-availability/xdcr-active-sgw-before-upgrade.png[,720,align=left]
+
+. Upgrade both clusters A and B with _all_ the nodes of the clusters to Server 7.6.6 or a later version.
+. Enable ECCV on bucket B1. All the mutations in B1, after this point of time, will have a new metadata called HLV.
++
+NOTE: ECCV refers to the bucket property `enableCrossClusterVersioning`. If there are more than two buckets in the replication topology, you must enable ECCV for all those buckets.
++
+. Enable ECCV on bucket B2. All the mutations in B2, after this point of time, will have a new metadata called HLV.
++
+NOTE: If there are more than two buckets in the replication topology, you must enable ECCV for all those buckets.
++
+. Update the replication settings to `mobile=Active` of the already existing XDCR from B1 to B2. 
++
+You can use the REST API or the XDCR UI to update an existing replication. For information about using the REST API to modify the replication settings for an existing replication, see xref:rest-api:rest-xdcr-adv-settings.adoc#change-existing-replication-with-mobile-active[Change Settings for an Existing Replication to Set mobile=Active] in xref:rest-api:rest-xdcr-adv-settings.adoc[Managing Advanced Settings].
++
+. Create an XDCR from B2 to B1 with the replication settings as `mobile=Active`. 
+. Upgrade SGW on cluster A to the version 4.0.0*.
+. Connect SGW version 4.0.0* to cluster B.
+. Enable application active traffic on cluster B. 
+
+This setup can handle application traffic on both buckets B1 and B2 of the respective clusters along with SGW import into both the buckets simultaneously.
+
+This is an illustration of the final configuration:
+
+.Replication after upgrade: XDCR Active-Active with SGW
+image::clusters-and-availability/xdcr-active-sgw-after-upgrade.png[,720,align=left]