Configure Bidirectional XDCR for Active‑Active Couchbase Clusters

Desired Outcome

Set up two‑way Cross Datacenter Replication (XDCR) between two Couchbase Server clusters so that mutations in either cluster are replicated to the other, enabling active‑active workloads and automated failover without manual data resync.

Prerequisites

• Two Couchbase Server clusters (same major version, e.g., 7.2.x) with network connectivity (TCP ports 8091, 8092, 11210 open).
• Administrator credentials for both clusters.
• A bucket (e.g., travel-sample) created on each cluster with identical name and SASL password (if any).
• Sufficient WAN bandwidth to sustain expected write throughput; estimate based on peak mutation rate.

Procedure

1. Prepare the source bucket on Cluster A
   1. Log into the Cluster A Admin UI at http://<cluster-a-host>:8091.
   2. Navigate to Buckets and ensure the target bucket exists.
2. Create unidirectional XDCR from A → B
   1. In Cluster A UI, go to XDCR → Replications and click Create Replication.
   2. Set:
   • Source Bucket: travel-sample
   • Target Cluster: http://<cluster-b-host>:8091 (provide admin username/password)
   • Target Bucket: travel-sample
   • Replication Type: Continuous
   • Conflict Resolution: leave default (Timestamp/CAS)
   3. Click Save.
3. Create unidirectional XDCR from B → A
   1. Repeat the same steps in Cluster B UI, swapping source and target.
4. Verify bidirectional setup
   1. In each cluster’s UI, under XDCR → Replications you should see two entries: one A→B and one B→A.

Expected Checks

• Status panel shows a green Running state and zero error counts for both replications after the initial bootstrap (may take several minutes depending on data size).
• Run a N1QL count on both clusters to confirm equality:

  # Run on Cluster A
  curl -u admin:password http://:8093/query/service -d '{"statement":"SELECT COUNT(*) AS cnt FROM `travel-sample`"}'
  # Run on Cluster B
  curl -u admin:password http://:8093/query/service -d '{"statement":"SELECT COUNT(*) AS cnt FROM `travel-sample`"}'
  

  The cnt values should match within a few seconds of replication lag.
• Check replication latency: in the XDCR UI, view the mutation_time metric; ensure it stays below your defined SLA (e.g., < 500 ms for low‑latency workloads).

Recovery Options

• Network partition: Pause the affected replication via UI (XDCR → Replications → Pause). Verify vBucket states with cbstats vbucket-details on both clusters. Once connectivity resumes, resume replication; if vBucket maps diverge, perform a manual rebalance on the target cluster (cbstats rebalance-status).
• Source cluster failure: Stop the data service on the failed cluster (couchbase-cli service-list -c --username admin --password --remove service=data). The target cluster continues to serve reads/writes. After recovery, re‑join the failed node and let XDCR catch up; no manual resync is required.
• Index recreation: Remember that secondary and FTS indexes are not replicated. After initial sync, create identical indexes on the target cluster using the same CREATE INDEX statements.

Limitations

• Both clusters must run the same major Couchbase version; mixing versions can break replication.
• XDCR does not replicate indexes automatically; plan for index creation on the target side.
• High latency or limited bandwidth increases replication lag and may affect RPO/RTO targets.