[SERVER-50964] Create temporary swappable promise construct in order to receive messages on the RecipientStateMachine Created: 15/Sep/20 Updated: 06/Dec/22 Resolved: 21/Oct/20 |
|
| 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 Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | PM-234-M2, PM-234-T-lifecycle | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Sharding
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Current rough draft implementation:
This will get us roughly a producer-consumer queue or mailbox of size one. |
| Comments |
| Comment by Blake Oler [ 21/Oct/20 ] | ||||||||||||||||||||||||||||||||||||||
|
renctan has completed this with | ||||||||||||||||||||||||||||||||||||||
| Comment by Janna Golden [ 24/Sep/20 ] | ||||||||||||||||||||||||||||||||||||||
|
I vote for alternative #2! | ||||||||||||||||||||||||||||||||||||||
| Comment by Max Hirschhorn [ 24/Sep/20 ] | ||||||||||||||||||||||||||||||||||||||
|
It sounds like the design for primary-only services intended to have the Instance be the exclusive writer to the state document. Alternative #2 - store progress in separate documentsWe could have a config.localReshardingOperations.recipient.progress_applier collection which stores a document
The ReshardingOplogApplier would update that document following applying a batch of oplog entries from that donor shard. Note that being able to apply batches from different donors independently is a recent outcome from changes to the rules for resharding's oplog application in the design document. Consider the following interface for the ReshardingOplogApplier:
The idea would be to have the RecipientStateMachine create a ReshardingOplogApplier instance for each donor shard upon transitioning into the "applying" state. And then blocking the transition into the "steady-state" state is all the future returned by awaitDoneApplyPhase() for each of the ReshardingOplogAppliers becoming ready. In other words, _cloneThenTransitionToApplying() would create the ReshardingOplogAppliers, _applyThenTransitionToSteadyState() would wait for then all to ready awaitDoneApplyPhase(), and _awaitAllDonorsMirroringThenTransitionToStrictConsistency() would wait for them all to ready awaitDoneCatchUpPhase(). Note that I'm not sure we would need RecipientStateMachine::_allDonorsMirroring because the ReshardingOplogApplier would implicitly need to wait for that state by waiting for the final oplog entry to come through. It is important that during recovery for the primary-only service that the ReshardingOplogApplier gets instantiated so its can recover whether to immediately ready its SharedPromises based on the contents of its progress document. I'm not prepared to make the leap of saying ReshardingOplogApplier ought to be its own separate primary-only service because I wasn't sure how well a primary-only service Instance deals with being co-managed by another primary-only service. We could explore that avenue too. Alternative #3 - have an OpObserver invalidate the recipient state document(Not going into as much depth here because I'm more in favor of Alternative #2.) RecoveryUnit::onCommit() handlers are called after the storage transaction has committed but while still holding locks. This means for IX writes to a collection, the onCommit() handlers may be called in a different order than the order of the optimes assigned to the storage transactions. We could do as |