-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Backup, Compaction
-
Storage Engines
-
5
-
2024-01-09 - I Grew Tired
The test should be extended with other scenarios as described in WT-12014 by sue.loverso@mongodb.com:
One extension to the test from
WT-11820would be in generate_data:
- split the populate to insert the first 50%, checkpoint, take the full backup (and/or start incremental).
- insert the latter 50%, checkpoint, (this will generate the bitmap showing changes in the back half of the table)
- remove the 50%
- ...compact...
Since the bitmap should never turn off a modified bit once it is set, either one of two things should happen during the next incremental backup. We should understand what WT does:
- WT returns a bit that is beyond the new/compacted end-of-file. The should be okay as lseek should succeed and read should return 0 bytes. I think this is the likely situation.
- WT detects this internally and returns a copy the whole file or indicates the cursor is done.
- has to be done before
-
WT-12014 Understand impact of incr backup and background compaction
- Closed