A newer version of this documentation is available.

View Latest


      Couchbase Server ensures the availability of data across the nodes of a cluster; across groups of nodes within the cluster; and across separate clusters, potentially located in different data-centers.

      Local and Remote Replication

      Couchbase Server supports two forms of replication.

      • Local, or intra-cluster replication involves replicating data across the nodes of a cluster. When a bucket is defined, it can be specified to have up to 3 replicas (the number actually implemented by Couchbase Server may be less, if there are too few nodes in the cluster). This allows data to be maintained and updated in replica copies, which can be made active in the event of node-failure rendering active data inaccessible. Intra-cluster replication is supported by the Data Change Protocol.

      • Remote, or Cross Data Center Replication (XDCR) is typically used to replicate data across different clusters, each of which may occupy a different data center. XDCR is configured after the creation of a suitable bucket on the local cluster, which will be the replication source, and another bucket on the remote cluster, which will be the replication target. Changes made to data within the source bucket are automatically replicated to the target bucket. Both source and target buckets can be accessed directly by applications: if both are indeed so accessed, XDCR replication is typically configured between them in both directions, so that each bucket is both a source and a target, and updated made on either cluster are replicated to the other.

      For more information on intra-cluster replication, see Intra-Cluster Replication.

      For more information on XDCR, see Cross Data Center Replication (XDCR).

      Server Group Awareness

      Individual server-nodes can be assigned to specific groups, within a Couchbase Cluster. This allows both active vBuckets and GSI indexes to be maintained on groups different from those of their corresponding replica vBuckets and index replicas; so that if a group goes offline, and active vBuckets and indexes are thereby lost, replicas remain available on one or more other groups.

      For more information, see Server Group Awareness.