[SERVER-35714] Recover to common point on rollback instead of stable timestamp Created: 20/Jun/18 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Backlog - Storage Engines Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Storage Engines
|
||||||||||||
| Participants: | |||||||||||||
| Story Points: | 0 | ||||||||||||
| Description |
|
Once we allow PIT reads on secondaries within previous batches, we should be able to simply recover to the common point on rollback instead of recovering to the stable timestamp and replaying the oplog to the common point. This will make rollback even faster and easier to understand. The recovery code can then only be used for startup recovery. |
| Comments |
| Comment by Brian Lane [ 22/Oct/19 ] |
|
Hi ratika.gandhi, We met to discuss this one, and I have put it in our backlog for now. In the future when we need to make some changes to the recovery code, doing this project could benefit by potentially letting us remove / simplify the startup recovery codebase. |
| Comment by Ratika Gandhi [ 29/Aug/19 ] |
|
This would be a significant optimization. Please consider doing this or close the ticket if you believe that we don't want to do it anymore. |