This is to address the issue of reaping across sync'd clusters. Without this feature it is necessary to disable full-sync whilst independently replicating on each cluster.
Now if reaping via riak_kv_reaper the reap will be replicated assuming the riak_kv.repl_reap flag has been enabled. At the receiving cluster the reap will not be replicated any further.
There are some API changes to support this. The find_tombs aae_fold will now return Keys/Clocks and not Keys/DeleteHash. The ReapReference for riak_kv_repaer will now expect a clock (version vector) not a DeleteHash, and will also now expect an additional boolean to indicate if this repl is a replication candidate (it will be false for all pushed reaps).
The object encoding for nextgenrepl now has a flag to indicate a reap, with a special encoding for reap references.
martinsumner
commented
1 year ago
This is to address the issue of reaping across sync'd clusters. Without this feature it is necessary to disable full-sync whilst independently replicating on each cluster.
Now if reaping via riak_kv_reaper the reap will be replicated assuming the
riak_kv.repl_reapflag has been enabled. At the receiving cluster the reap will not be replicated any further.There are some API changes to support this. The
find_tombsaae_fold will now return Keys/Clocks and not Keys/DeleteHash. The ReapReference for riak_kv_repaer will now expect a clock (version vector) not a DeleteHash, and will also now expect an additional boolean to indicate if this repl is a replication candidate (it will be false for all pushed reaps).The object encoding for nextgenrepl now has a flag to indicate a reap, with a special encoding for reap references.
Clarify specs
Take timestamp at correct point (after push)
Updates following review
Update rebar.config