[SERVER-52743] Allow donors to potentially skip the mirroring state, and go directly into dropping or done Created: 10/Nov/20 Updated: 06/Dec/22 Resolved: 05/Mar/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding NYC
|
| Participants: | |
| Story Points: | 2 |
| Description |
|
There exists an edge case where a donor could be told to go into dropping after kPreparingToMirror. This is possible in this scenario:
This ticket is to ensure that it won't break code for a donor to transition directly from kPreparingToMirror to kDropping. |
| Comments |
| Comment by Max Hirschhorn [ 02/Feb/21 ] |
|
blake.oler, if we require that DonorStateMachine must always transition from DonorState::kPreparingToMirror to DonorState::kMirroring, then does anything go wrong? My understanding is that the donor shard would (1) write out new reshardFinalOp no-op oplog entries which would be ignored by the recipient shards (since they have already received such a no-op oplog entry from this donor shard before), (2) transition to DonorState::kMirroring, and (3) immediately transition again to DonorStateEnum::kDropping because the _coordinatorHasDecisionPersisted future has become ready in the meantime. |