[SERVER-55032] Get rid of ShardingStateRecovery once 5.0 branches out Created: 08/Mar/21 Updated: 05/Dec/22 Resolved: 21/Sep/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Pierlauro Sciarelli | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | 5.0-cleanup, sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Sharding EMEA
|
||||||||||||||||||||||||
| Sprint: | Sharding EMEA 2021-10-18 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
The ShardingStateRecovery machinery can be fully replaced by the waitFor* and recovery methods offered by the VectorClockMutable. |
| Comments |
| Comment by Githook User [ 08/Oct/21 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| Comment by Pierlauro Sciarelli [ 21/Sep/21 ] |
|
Closing because of the reasons explained in the comment. Opened |
| Comment by Jordi Serra Torrens [ 11/Aug/21 ] |
|
ShardingStateRecovery cannot yet be thrown out on 5.1. Some context first: ShardingStateRecovery does the following on stepup Currently, ShardingStateRecovery is critical for the correctness of these two operations: chunk migration and movePrimary.
The guarantee (a) could be replaced by the VectorClock::waitForDurableConfigTime. This way, ShardingStateRecovery would no longer need to make configOpTime durable, and instead we'll rely on the VectorClock recovery. ShardingStateRecovery would still be needed for guarantee (b) required by movePrimary. However, it is not possible to throw away (a) in 5.1. The reason is that in multi-version clusters (5.0 <--> 5.1), we never recover the VectorClock on stepup. Because of that, the following situations could happen:
Similar reasoning should apply to movePrimary Possible course of action:
|