There may be some situations whereby a vector clock grows beyond the prescribed limits on the source cluster - in particular following read repair.
In these cases the new object needs to be replicated but with the same resulting vector clock (assuming no siblings). If the same vector clock does not result on the sink - any full-sync operation may continuously detect the delta, but not be able to resolve it (as the sink vnodes prune each time).
The 'rr' option will, on riak_kv_vnode, ensure pruning is bypassed so that we avoid pruning on a sink, if we have not pruned on a source. The 'rr' option is only used when the clock is prunable (as otherwise the delta could occur in the reverse direction).
The 'rr' option also blocks some sibling constraint checks (e.g. maximum number of siblings. However, as the most likely cause of it being applied is 'rr' on the src side - this is still generally a win for replication consistency).
martinsumner
commented
1 year ago
There may be some situations whereby a vector clock grows beyond the prescribed limits on the source cluster - in particular following read repair.
In these cases the new object needs to be replicated but with the same resulting vector clock (assuming no siblings). If the same vector clock does not result on the sink - any full-sync operation may continuously detect the delta, but not be able to resolve it (as the sink vnodes prune each time).
The 'rr' option will, on riak_kv_vnode, ensure pruning is bypassed so that we avoid pruning on a sink, if we have not pruned on a source. The 'rr' option is only used when the clock is prunable (as otherwise the delta could occur in the reverse direction).
The 'rr' option also blocks some sibling constraint checks (e.g. maximum number of siblings. However, as the most likely cause of it being applied is 'rr' on the src side - this is still generally a win for replication consistency).
https://github.com/basho/riak_kv/issues/1864