[SERVER-52693] Have ReshardingCollectionCloner retry cloning on retryable errors from the donor shards Created: 09/Nov/20 Updated: 29/Oct/23 Resolved: 06/Jan/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Max Hirschhorn |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-234-M3, PM-234-T-data-clone | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2021-01-11 | ||||||||||||
| Participants: | |||||||||||||
| Story Points: | 2 | ||||||||||||
| Description |
|
Since the RecipientStateMachine is responsible for accumulating the mongo::Futures returned from multiple components, it is simpler for RecipientStateMachine if it can assume any errors are fatal for the resharding operation. That is, the RecipientStateMachine machine won't be responsible for restarting a particular component on a retryable error from a donor shard and instead each individual component is responsible for restarting itself. This likely would be implemented by using AsyncTry within the run() method of each of the components. |
| Comments |
| Comment by Githook User [ 06/Jan/21 ] |
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: |