[SERVER-5160] Handle all failed shardCollection commands well Created: 01/Mar/12 Updated: 06/Dec/22 Resolved: 16/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Greg Studer | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Done | Votes: | 6 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Assigned Teams: |
Sharding EMEA
|
||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||
| Description |
|
Two parts - make subsequent shardCollections possible without flushing configuration, and handle failed splitVector command by creating default Min->Max chunk and printing a warning of some kind. Additionally, if there are network troubles it is possible for a shardCollection command to fail halfway through, in a state where the collection is not fully sharded, but extra chunk entries have been created that prevent another shardCollection call from working. In this case, a rollback to the unsharded state should be attempted, both by the initial failed shardCollection command, as well as by the subsequent shardCollection command if necessary (for instance, if network issues persist that prevent the first command's rollback from working). |
| Comments |
| Comment by Kaloian Manassiev [ 16/Nov/21 ] |
|
This problem no longer exists as of the DDL improvements done in 5.0. |
| Comment by Sheeri Cabral (Inactive) [ 09/Dec/19 ] |
|
shardCollection is not transactional so rollback isn't self-correcting at this point. |