nickva opened a new pull request, #6210:
URL: https://github.com/apache/couchdb/pull/6210
Observed a few rare cases of purges being stuck in production
We had the wrong field name in read repair purge checkpoint filter. Before
we looked up `target_node` in the purge checkpoint docs but it should really be
`target` (see mem3_rep:purge_cp_body/3). This way every node started at purge
seq 0.
`pull_purges/5` had the target/source swapped. The checkpoint lives on the
target so we should always write it from the target's perspective, meaning the
target is the source and we're the target.
There was an off-by-one error in `have_all_purge_checkpoints/1`
Shards db checkpoints have an undefined range (since they are effectively
local dbs replicated in special ring topology) and they replicated by name. As
such they never matched the `{Node, [0, ?RING_END]}` copies so
`have_all_purge_checkpoints/1` was always false for them.
Fortunately this is easy to fix, and just deleting the checkpoints and
letting the next internal replication cycle start over from the oldest purge
seq works.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
