Use 'RR' when a prunable vclock is replicated #1866
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).
#1864