[SERVER-48153] Chunk migration can still be running even after the moveChunk command fails with maxTimeMS timeout Created: 12/May/20 Updated: 26/Oct/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | oldshardingemea, sharding-common-backlog, shardingemea-qw | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||||||||||||||
| Description |
|
This means that running a new migration immediately after a previous one failed with timeout can fail because there's a conflicting chunk migration in progress. |
| Comments |
| Comment by Connie Chen [ 21/Dec/22 ] |
|
After scoring this ticket, we think it is unlikely that we will do this in the near future, but we'll keep it in our QWs bucket |
| Comment by Esha Maharishi (Inactive) [ 13/May/20 ] |
|
Changing from "Bug" to "Improvement" because this works as designed, though it would be nice if either: 1) The later migration could block behind the first one, or 2) The first migration could be aborted if the client's maxtTimeMS expired on the donor and the donor had not sent commit to the config server yet.
This is also related to the idea of long-running commands returning quickly to the client and their progress being poll-able. |