A newer version of this documentation is available.

View Latest

Cross Data Center Replication (XDCR)

One of the Couchbase data platform’s key features is the ability to replicate bucket data in another geographically remote location to provide resilience in the event of a network or power fault. This section outlines a few scenarios and how to configure your Couchbase clusters accordingly.

XDCR Within the Same Kubernetes Cluster

This is by far the simplest deployment. Since both Couchbase Server clusters are in the same pod network, and both have access to DNS, XDCR will just work out of the box. TLS can also be used to secure communications with a wildcard certificate.

XDCR to a Different Kubernetes Cluster with Routed Networking

If the pod networks are able to communicate with each other, and you are using a service mesh which is able to replicate the cluster DNS records, then XDCR will work once the service that is automatically created for the cluster has been manually replicated in the remote cluster. As DNS is available, TLS can also be used to secure communications with a wildcard certificate.

For all other situations, you will need to enable the XDCR exposed feature in the cluster specification. TLS is currently not supported, since addressing is via IP address.

Clusters in Different Clusters with Overlay Networking

You will need to enable XDCR under exposedFeatures in the cluster specification. TLS is currently not supported since addressing is via IP address.

The XDCR exposed feature exposes pod ports as node ports. Clients that are aware of this extension are able to access the cluster services via node IP address and node port. As a result, the client must be able to route to the destination node network.