-
Type: Task
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.5.10
-
Component/s: Sharding
-
None
-
Minor Change
-
Sharding 2017-07-31, Sharding 2017-08-21, Sharding 2017-09-11, Sharding 2017-10-02, Sharding 2017-10-23
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
- depends on
-
SERVER-31068 make config server update fcv 'targetVersion' at beginning of _configsvrSetFeatureCompatibilityCommand
- Closed
- is duplicated by
-
SERVER-30459 shardCollection should fail if running in a mixed-FCV cluster
- Closed