[SERVER-37967] Backup cursor truncate after test can choose to recover before the checkpoint timestamp Created: 06/Nov/18 Updated: 29/Oct/23 Resolved: 12/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.6 |
| Type: | Bug | 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 | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Storage NYC 2018-11-19 | ||||
| Participants: | |||||
| Linked BF Score: | 56 | ||||
| Description |
|
The backup_cursor_truncate_after test will always try setting the truncate after point to the top of oplog. However, that timestamp is "inclusive" meaning replication recovery will try to remove that document. If that oplog entry is also the checkpoint timestamp, that document is majority committed and cannot be removed. The test should omit that scenario when it occurs. |
| Comments |
| Comment by Githook User [ 17/Nov/18 ] |
|
Author: {'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}Message: |
| Comment by Githook User [ 12/Nov/18 ] |
|
Author: {'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}Message: |