A newer version of this documentation is available.

View Latest

Tune XDCR Performance


    Full, Cluster, and Replication Administrators can adjust the advanced settings to tune the XDCR performance.

    By default, XDCR gets metadata for documents over 256 bytes twice before it performs conflict resolution for them at a destination cluster. If the document fails conflict resolution, it is discarded at the destination cluster. If a document is smaller than the number of bytes provided with this parameter (256 bytes), XDCR immediately puts it into the replication queue without getting metadata on the source cluster.

    If the document is deleted on the source cluster, XDCR will no longer fetch metadata for this document before it sends the update to the destination cluster. Once the document reaches the destination cluster, XDCR will fetch the metadata and perform conflict resolution between documents. If the document ‘loses’ conflict resolution, Couchbase Server discards it on the destination cluster and keeps the version on the destination. This new feature improves replication latency, particularly when you replicate small documents.

    There are tradeoffs when you change this setting.

    • If you set the optimistic replication threshold low compared to the document size, the source cluster will have to frequently check the metadata of the document on the remote cluster. This means that latency increases during replication as the source cluster also has to fetch the metadata prior to (possibly) adding the document to the replication queue. The advantage is that you do not use unneccessary network bandwidth in situations where the remote cluster already has the same copy of the document.

    • If you configure this setting very high relative to the document size, XDCR fetches less metadata and latency will improve during replication. High setting also means that you will increase the rate at which XDCR puts items immediately into the replication queue; this can potentially overwhelm your network, especially if you set a high number of parallel replicators. The number of documents sent by XDCR, therefore, might be increased, and network bandwidth misused.

    The following advanced settings are related to XDCR performance:

    • optimisticReplicationThreshold

    • sourceNozzlePerNode

    • targetNozzlePerNode

    XDCR does not fetch metadata for the deleted documents.

    Changing the Document Threshold

    Change the document threshold with the REST URI

    /settings/replications optimisticReplicationThreshold

    and the parameter for XDCR advanced settings. Alternatively, change the XDCR Optimistic Replication Threshold setting for the XDCR replication.

    Replication Statistics

    The provided statistics is docs_ fail_ cr_source, which is the number of big documents that have failed conflict resolution on the source and have not been replicated to the target cluster.

    Bucket Flush with XDCR

    The flush operation deletes data on a local bucket.

    XDCR does not replicate flush requests to delete the entire content of the Couchbase bucket. The flush option is disabled if an active outbound replica stream is configured.

    If the Couchbase bucket needs to be flushed either on the source or on the destination of an XDCR replication, use the following operation sequence:

    1. Delete the XDCR replication.

    2. Flush the Couchbase bucket.

    3. Recreate the XDCR replication.

    If the Couchbase bucket needs to be flushed on the source side of an XDCR replication, all replications must be deleted before the flush and recreated afterward.

    Deleting and recreating the XDCR replication will reset the replication and resend the data, unless the data has been synchronized.

    When replicating to or from the Couchbase bucket, do not flush that bucket on the source or destination cluster. Flushing causes the Couchbase bucket’s state to become temporarily inaccessible and results in a not_found error. This error suspends replication.