[SERVER-30358] shardCollection should ask primary shard for collection UUID if in schema version 3.6 Created: 26/Jul/17  Updated: 12/Oct/17  Resolved: 05/Oct/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.5.10
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-31068 make config server update fcv 'target... Closed
Duplicate
is duplicated by SERVER-30459 shardCollection should fail if runnin... Closed
Backwards Compatibility: Minor Change
Sprint: Sharding 2017-07-31, Sharding 2017-08-21, Sharding 2017-09-11, Sharding 2017-10-02, Sharding 2017-10-23
Participants:

 Description   

shardCollection should not be allowed to run in a mixed-FCV cluster, because it can result in the collection that is being sharded not having a UUID stored in config.collections on the config server:

1) setFCV="3.6" called against a mongos, which forwards _configsvrSetFCV to the config server
2) configsvrSetFCV finishes generating UUIDs for existing sharded collections
3) shardCollection is called
--> the FCV on the config server has not been set to 3.6 yet, so shardCollection will not ask the primary shard for a UUID
--> and even if it did ask, the primary shard may not have had setFCV called on it yet, and so would not return a UUID
--> so an entry for the newly sharded collection will get written to config.collections without a UUID



 Comments   
Comment by Esha Maharishi (Inactive) [ 05/Oct/17 ]

Will be fixed as part of SERVER-30745.

Comment by Esha Maharishi (Inactive) [ 12/Sep/17 ]

The linked ticket SERVER-31068 will prevent a 3.4 mongos from talking to the config server, which simplifies this considerably. Local locks can be used to prevent _configsvrSetFeatureCompatibilityVersion from running concurrently with the metadata commands mentioned.

Comment by Esha Maharishi (Inactive) [ 26/Jul/17 ]

Considered a "minor" backwards-breaking change, since movePrimary and shardCollection were previously allowed to run during upgrade.

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