[SERVER-63652] Donor starts shard split operation in kBlocking Created: 15/Feb/22 Updated: 29/Oct/23 Resolved: 18/Mar/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Matt Broadstone | Assignee: | Didier Nadeau |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Server Serverless 2022-03-21 |
| Participants: |
| Description |
|
Today we start a shard split operation with either a kUninitialized or kAborted state written to the durable state document, which can be problematic because a stepdown between initial state document insertion and transition to the first state (kBlocking) will result in trying to re-insert the state document when a secondary steps up. We should never write kUninitialized to disk, and instead make transition to kBlocking the first write (if not aborted). |
| Comments |
| Comment by Githook User [ 18/Mar/22 ] |
|
Author: {'name': 'Didier Nadeau', 'email': 'didier.nadeau@mongodb.com', 'username': 'nadeaudi'}Message: |