[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:
Depends
Duplicate
is duplicated by SERVER-10653 unable to shard collection with colle... Closed
Related
related to SERVER-10012 Segmentation fault on splitChunk Closed
related to SERVER-13043 shardCollection don't behave properly Closed
related to SERVER-44052 Inconsistencies in sharded collections Closed
Assigned Teams:
Sharding EMEA
Operating System: ALL
Participants:
Case:

 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.

Generated at Thu Feb 08 03:08:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.