[SERVER-34659] Reevaluate whether a forced refresh is necessary in the commit phase of the MigrationSourceManager Created: 24/Apr/18 Updated: 06/Dec/22 Resolved: 22/Jan/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.7.6 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Participants: |
| Description |
|
Currently, the MigrationSourceManager forces a fresh of sharding metadata after a commit has been attempted, no matter whether the commit succeeds or fails. A refresh is costly and shouldn't be necessary every time. Instead, we should do the following:
That assures the following behavior: If the commit fails, then when attempting to access this chunk, the source shard will refresh from the config server and reassume ownership for that chunk. If the commit succeeds, then when attempting to access this chunk, the source shard will refresh from the config server and find out it's not the owner of the chunk. The mongos will then reroute access to the destination shard. |
| Comments |
| Comment by Gregory McKeon (Inactive) [ 22/Jan/19 ] |
|
We're going to need to come up with a more complete solution after doing |