Bucket Conflict Resolution

Couchbase Server
1

HI!
I’m curious to know more use-case scenarios for deciding on Bucket Conflict resolution either Sequence or Timestamp. According to the docs, I assume that most XDCR enabled buckets should be set to Timestamp. Is that correct? Such as: High Availability with Cluster Failover

These are good examples:
Example 1 - Most Updates is Best

Consider a hit counter for a website, stored as a counter document within Couchbase Server which is incremented on every access. In the event of a conflict occurring, you would want the version of the document has been incremented the most, as that will more closely reflect the actual count. Revision ID-based conflict resolution would be preferable in this instance as it ensures that the document which has been mutated the most ‘wins’.

Example 2 - Most Recent Update is Best

Consider a thermometer device which stores the current temperature in Couchbase Server, writing to the same key repeatedly. In the event of a conflict occurring, you would want to keep the version of the document which was captured most recently, as that is the most accurate ‘current’ temperature. Timestamp-based conflict resolution ensures that the most recent version of the document would be used.

I’m confused about XDCR - lets say you have a similar use case as above with a Counter - but you want to use XDCR… Would you set it to Timestamp because it’s most appropriate for XDCR or would you use Sequence.

Thanks,
Will

2

Hi,

Conflict resolution is applicable for an active-active setup of XDCR where documents are modified concurrently from different servers before synchronization. You can use either of the modes. One caveat with most updates approach is that most number of updates is not necessarily reflective of the most recent update. This will be bubbled up during bidirectional replication scenarios where as indicated in documentation, “For conflict resolution between an incoming mutation from another cluster and a local mutation in the current cluster, if the incoming mutation does not have a higher revision ID than the local mutation, it will be discarded and will not be stored. In the case of bidirectional replication, this process results in the mutation with the highest revision ID taking precedence on both clusters.” Hence, we recommend time-stamp based approach (last write wins) more often.

Both of these modes are applicable only for XDCR.