[SERVER-63248] Defragmenter should not retry StaleShardVersion Created: 03/Feb/22 Updated: 29/Oct/23 Resolved: 07/Feb/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.3.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Allison Easton | Assignee: | Tommaso Tocci |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | Sharding EMEA 2022-02-07, Sharding EMEA 2022-02-21 | ||||
| Participants: | |||||
| Linked BF Score: | 59 | ||||
| Description |
|
If a chunk migration is submitted with the bounds of a chunk that no longer exists, theĀ error returned is a stale shard version error. The defragmentation algorithm is currently using stale shard version errors to trigger retrieving the new shard version, but is keeping the in memory state of the phase and issuing the same request with the new shard version. In the case of a chunk whose bounds have changed, though, this means the same movechunk request will be continuously issued and failed. We need to either not count stale shard versions as retriable, or somehow distinguish between actual stale shard version errors and chunk boundary errors. |
| Comments |
| Comment by Githook User [ 07/Feb/22 ] |
|
Author: {'name': 'Tommaso Tocci', 'email': 'tommaso.tocci@mongodb.com', 'username': 'toto-dev'}Message: |