XDCR, by design, provides customers the flexibility to tune the number of replications for a given bucket depending on the desired performance. New replication requires streaming all existing documents in the bucket, and, therefore, it exhibits a higher mutation rate than ongoing mutations. As such, new replication uses more resources, which would sometimes negatively impact the throughput of existing replications in the meantime. With our upcoming 6.5 release, XDCR will provide users the ability to prioritize ongoing replications over initial replications. Resource allocation will happen based on the specified priority.
When creating a new replication, the customer has a choice to assign priorities to the replication stream. The options provided would be HIGH, MEDIUM or LOW.
For our understanding, let’s assume that on-going replications are HIGH and consider the below mentioned scenarios for new replications :
HIGH :
The maximum resource allocation would be provided to this new replication during the initial backfill stage (until all the mutations in the source bucket are replicated to target bucket). This may have some negative impact on the performance of existing replications.
This can be extremely useful in workload distribution and data locality use cases where the customers would want to get a new cluster added to the topology, have it up and running immediately and would like to ensure consistency across clusters as soon as possible.
This is the current XDCR behavior and will also be the default configuration.
MEDIUM :
The new replication will be given minimal resources during the backfill stage to slowly catch up to be in parity with the on-going replications. Once, the replication is all caught up, the priority for this replication stream will automatically be changed to HIGH and the resource distribution will be uniform across all HIGH replications.
This is a useful setting for high availability and disaster recovery use cases. When a customer does not want to have any negative impact to the existing clusters and can afford to wait for a new cluster to be caught up, this is a perfect setting.
LOW :
The new replication will be given minimal resources throughout the replication process. During initial replication and during on-going replication stages, this stream will be given lower priority.
This is a useful setting when a customer wants to set up a hot and cold cluster, where they can afford slow replication performance for the cold cluster with minimal resource allocation.
For the users of XDCR, there only one visible change:
A new replication setting, “Priority”, will be added to replication creation and edit views. It will take three possible values, High/Medium/Low.
As replication performance is heavily dependent on network bandwidth and allocated CPU, customers can allocate the priorities depending on the criticality of the business need and conserve resources. Effective utilization of this functionality by assigning priorities based on the business need could lead to reduced cost of ownership especially for cloud deployments.
The resource management updates via assigning priorities is completely optional. They can be modified at any point in the future, without any negative impact such as replication restarts.
Replication prioritization provides customers with improved control over their resource management. This feature improves XDCR’s overall replication behavior as we can choose to not have any impact on on-going replications due to newly created replications.
All these changes can also be made via CLI/REST API. For more details, please read documentation.
Please share your experience on using this feature via comments or in our forum.
Resources
Download
Documentation
Couchbase Server 6.5 Release Notes
Couchbase Server 6.5 What’s New
Blogs
Blog: Announcing Couchbase Server 6.5 GA – What’s New and Improved
Blog: Couchbase brings Distributed Multi-document ACID Transactions to NoSQL
Hi Chaitra,
In the section that describes the behaviour for MEDIUM, you mentioned
“When a customer does not want to have any negative impact to the existing clusters and can afford to wait for a new cluster to be caught up, this is a perfect setting.”
So the assumption is that there are already 2 (or more) clusters and hence there is already XDCR setup between those clusters and now a 3rd cluster is being added. Believe, the same will apply in case there are already 2 clusters in XDCR and a new replication is being created for a bucket (that was not previously replicated). So backfill for this bucket will happen with minimal resource allocation whereas ongoing replications (for other buckets between the same 2 clusters) will continue at HIGH priority.
So even for on-going replications, there is a change i.e. priorities will apply. However 3 priorities (HIGH/MEDIUM/LOW) will be available for new replications whereas for ongoing replications, there will be only 2 (HIGH/LOW).
So XDCR 6.5 release, will not just provide the ability to prioritize ongoing replications over initial replications; it also brings in priority among on-going replications, isnt it?
Thanks