Recovering databases with purges not replicated after nodes in maintenance_mode
- Dominant language
- Erlang
- Stars
- 7k
- Forks
- 1.1k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 9
Description
[NOTE]: # ( ^^ Provide a general summary of the issue in the title above. ^^ )
## Description
[NOTE]: # ( Describe the problem you're encountering. )
[TIP]: # ( Do NOT give us access or passwords to your actual CouchDB! )
I have a cluster with 6 nodes, with big databases (> 220M documents).
Each database lives with many creations, updates and purges (no deletion). Exceptionnaly, I set my nodes in maintenance_mode for a long time (16h) and discovered that purges were not replicated in nodes with maintenance_mode to true.
After a quick search, I found this issue (https://github.com/apache/couchdb/issues/2139) which correspond to my anomaly.
I've upgraded a test environment to v3.3.2 and the anomaly is well corrected for **new** purges. But is there a way to recover **old** purges and how should I do it ?
Thanks for your support.
## Steps to Reproduce
[NOTE]: # ( Include commands to reproduce, if possible. curl is preferred. )
- Put a node in maintenance mode
- Purge a document
- Put back the node from maintenance mode
- Migrate to 3.3.2
- The purge is still not replicated
## Expected Behaviour
[NOTE]: # ( Tell us what you expected to happen. )
Documents purged are purged in every node.
## Your Environment
[TIP]: # ( Include as many relevant details about your environment as possible. )
[TIP]: # ( You can paste the output of curl http://YOUR-COUCHDB:5984/ here. )
* CouchDB version used: 3.2.3
* Browser name and version: not relevant
* Operating system and version: Ubuntu 18.04
## Additional Context
[TIP]: # ( Add any other context about the problem here. )
Contributor guide
Research direction
Read the linked issue #2139 and the CouchDB 3.3.2 changes addressing purge replication first. The report gives a six-node maintenance-mode scenario but does not identify a recovery command, relevant source files, or tests. Determine whether old purges can be recovered and document or test the supported approach; the issue provides no specific entry point to start from.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- erlang
- Domain
- databases, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100