[SERVER-66480] Create a new command to join a generic chunk migration on a donor/recipient shard. Created: 16/May/22 Updated: 29/Oct/23 Resolved: 24/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0-rc8, 6.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Paolo Polato | Assignee: | Paolo Polato |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v6.0
|
||||||||||||
| Sprint: | Sharding EMEA 2022-05-30 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 171 | ||||||||||||
| Description |
|
On startup time, the Balancer needs to wait for the completion of all the outstanding chunk migrations executed across the cluster before generating new requests. In the past this was achieved by persisting in config.migrations a recovery doc for every moveChunk requested and repeating the command for every unanswered one upon a config server step down/crash. The same approach cannot be adopted to recover moveRange commands (which semantics are slightly different) without causing undesired side effects when the cluster gets downgraded. A more generic alternative could be built upon a new command that allows a client to wait until the contacted shard is no longer involved in any migration activity. |
| Comments |
| Comment by Githook User [ 29/May/22 ] |
|
Author: {'name': 'Paolo Polato', 'email': 'paolo.polato@mongodb.com', 'username': 'ppolato'}Message: (cherry picked from commit 531dfe764bc0645f5e676feaf5687100c0a5e612) |
| Comment by Paolo Polato [ 24/May/22 ] |
|
Author: {'name': 'Paolo Polato', 'email': 'paolo.polato@mongodb.com', 'username': 'ppolato'}Message: |