[SERVER-36200] Create a BackupCursorService class to manage backup cursor ownership Created: 19/Jul/18  Updated: 29/Oct/23  Resolved: 24/Jul/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.1.2

Type: New Feature Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Storage NYC 2018-07-30
Participants:

 Description   

Only one WT backup cursor can be open at a time. The fsync + lock command opens a backup cursor which is kept open until `fsyncUnlock` is called.

The new filesystem backup story will continue to use backup cursors, but via a different command (that among other things, does not take out a global exclusive lock). There will also be new storage engine API methods for working with the new filesystem backup story.

This ticket is to create a service class that sits above the storage engine that will dictate the semantic that only one cursor is allowed open at a time. Also part of this ticket is having `fsyncLock/Unlock` go through this service class.

New methods for the upcoming backup work should not be speculatively done as part of this ticket.



 Comments   
Comment by Githook User [ 24/Jul/18 ]

Author:

{'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}

Message: SERVER-36200: Add backup cursor service foundation. Have fsync command use it.
Branch: master
https://github.com/mongodb/mongo/commit/68be3d2abf4df873bd1355f7bfd6e086a6d0b173

Generated at Thu Feb 08 04:42:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.