[SERVER-48707] Disable replication recovery invariant that stableTimestamp equals appliedThrough Created: 11/Jun/20 Updated: 29/Oct/23 Resolved: 12/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.0-rc10 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | William Schultz (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 | ||||||||||||
| Backport Requested: |
v4.2, v4.0
|
||||||||||||
| Sprint: | Repl 2020-06-15 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
To support downgrade from 4.6 to 4.4 after removal of the stable optime candidates list, which will allow the stable timestamp to be set at a timestamp in the middle of a secondary batch, we should disable this invariant in replication recovery in 4.4. To see if the invariant catches any remaining storage engine bugs in our test infrastructure, we can allow the invariant to be enabled via a failpoint that we will enable in testing. |
| Comments |
| Comment by Githook User [ 12/Jun/20 ] |
|
Author: {'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}Message: |