Details
-
Bug
-
Resolution: Fixed
-
Critical
-
4.6.4, 4.6.3, 4.6.5, 5.5.0, 5.5.1, 5.5.2, 5.5.3, 5.5.4, 5.5.5, 5.5.6, 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.5.1, 6.6.0, 6.6.1, 6.6.2, 6.5.2, 6.5.0, 7.0.0
-
Untriaged
-
1
-
No
Description
What's the issue?
As a space saving measure during a merge, 'cbbackupmgr' will discard tombstones where the sequence number is larger than the purge sequence number. When paired with the existing forward merge logic, this result in backups which contain "revived" documents.
Steps to reproduce
1) Spin up a single node cluster
2) Limit it to 1 vBucket (must be CC+)
3) Create 4 documents (key1, key2, key3, key4)
4) Take a backup
5) Delete 2 documents (key1, key4)
6) Mutate a single document (key5)
7) Take a backup
8) Mutate a single document (key 2)
9) Perform an unsafe purge
10) Take a backup
11) Merge all the previous backups
We should see the merge complete successfully, whilst reporting that a single tombstone was "skipped".
Using 'info' to look at the data, we'll see:
|
Info Output |
- Bucket | Size | Items | Mutations | Tombstones | Views | FTS | Indexes | CBAS |
|
- default | 196.28KiB | 5 | 4 | 1 | 0 | 0 | 0 | 0 |
|
Note that we have four mutations, and only a single tombstone; key1 was "revived".
What's the fix?
We should remove the logic which is in place to skip purged tombstones during a merge.
