[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: |