-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Backup, Checkpoints
-
None
-
Storage Engines
-
StorEng - Defined Pipeline
In HELP-63834 a compaction prevented a backup cursor (at a high level) from being opened (on MongoDB 5.0.x).
At a higher level, MongoDB gets the checkpoint timestamp before opening a backup cursor, then opens the WT backup cursor, and then queries the checkpoint timestamp a 2nd time. If they match, the system can be assured that the backup is at that timestamp for point-in-time restores. If they don't match the system closes the backup cursor and retries several times for the timestamps to match and then finally gives an error.
In the ticket, a compaction prevented the backup from happening because WT does a lot of checkpoints internally which will keep moving the checkpoint timestamp.
This ticket should consider if the introduction of background compaction will exacerbate this potential issue. If so, how can we mitigate it?
- depends on
-
WT-13508 Test to identify the impact of compact and backup running concurrently.
- Open
- duplicates
-
WT-11709 API to retrieve timestamp of a checkpoint cursor
- Closed
- is depended on by
-
SERVER-81208 Use checkpoint cursor timestamp when opening backup cursor
- Open
- is related to
-
WT-11709 API to retrieve timestamp of a checkpoint cursor
- Closed
- related to
-
WT-13325 Investigate if background compaction should be paused when a backup cursor is active
- Open