We are not sure to understand ‘Optimistic Replication’ introduced with v2.1 and the optimal level we should set xdcrOptimisticReplicationThreshold when XDCR is used for disaster recovery only.
What we understand when XDCR is used for Disaster recovery only, is that there should be no conflicts resolution to loose on the destination, because destination is not accessed and updated by any app or any couchbase operation except XDCR.
Could you please confirm that when no create or update (set, incr, etc) are done on the XDCR destination cluster, xdcrOptimisticReplicationThreshold should be set really high (at a level matching the size of the biggest item in the bucket ), so that metadata are never read on the source cluster before putting the item in the replication queue ?
With optimistic replication turned 'OFF' or set to (20MB). All documents from the source cluster will be sent to target cluster with KEY , META and VALUE. Then conflict resolution will still work on the target cluster before SET().
Only difference is that with Optimistic Replication turned 'ON' and set to (256B) the source cluster will send to the target cluster KEY and META only of docs VALUE size of > 256B. Then if the Target says I want that doc to the source cluster the source cluster will send the KEY, META and VALUE. Then target cluster will do conflict resolution before SET(). The Idea is that document who's value is less then 256B is so small you might as well sent the full doc on the first trip to the target cluster.
NOTE that this setting is cluster wide and effects all buckets.
Thank you for this answer, but that was not my question.
My point is : what kind of conflict resolution do you need to do on a destination cluster where no update or delete are ever done (because this destination cluster is used for disaster recovery only, and never accessed by any app)
In this particular case, isn´t it better to avoird unnecessary metadata double check and any delay before sending the item to replicate (including its value), assuming that no conflict resolution could lead to a key being ‘newer’ on the destination cluster than it is on the source cluster ?
In your case the double check would not be much of a benefit. So setting optimistic replication to 20MB would save the target cluster some work. Also if you want to speed up XDCR you can tweek the couchbase settings such as batch number of items sent(Default 500) , number of xdcr connections (Default 32) and/or batch size of items sent(default 2048). Please note you will have to have the Bandwidth and hardware to take advantage of these features.