For sharding we need to know whether an upgrade or downgrade is in process, so in the setFeatureCompatibilityVersion command, where we set the schema version (featureCompatibility.isSchemaVersion36, we need to majority write a targetVersion field in the feature compatibility document with value "3.4" or "3.6" depending on the target schema version.
Before successful completion, the targetVersion field must be cleared. Upgrade/downgrade must be idempotent. As the parser for the setFeatureCompatibilityVersion needs to be changed, we should aim to transition it to IDL unless that expands the scope of this ticket too much.
- causes
-
SERVER-31783 Secondaries may generate a UUID for a replicated collection on their own while upgrading to fCV=3.6
- Closed
- is depended on by
-
SERVER-30515 disallow initiating cluster FCV downgrade in the middle of upgrade (and vice versa)
- Closed
-
SERVER-31068 make config server update fcv 'targetVersion' at beginning of _configsvrSetFeatureCompatibilityCommand
- Closed