-
Type: Improvement
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Internal Code
-
None
-
Fully Compatible
-
Query 2016-09-19
The mongos implementation of setFeatureCompatibilityVersion works simply by calling the internal _configsvrSetFeatureCompatibilityVersion command on the primary shard of the config server replica set. In the implementation of this internal command, the config server does the following:
// Set featureCompatibilityVersion on self. FeatureCompatibilityVersion::set(txn, version); // Forward to all shards. uassertStatusOK(Grid::get(txn)->catalogManager()->setFeatureCompatibilityVersionOnShards(txn, version)); return true;
Namely, it sets its own state and then forwards the sFCV() command to all shards, failing if any of the shards fail. This leads to the following problem scenario:
- Mongos sFCV("3.4") calls _configsvfSFCV("3.4") on the primary shard of the config server replica set.
- The config server successfully sets its own state to "3.4".
- Due to, say, a network problem, sFCV() on one of the shards fails.
Now the config server primary will report "3.4" as its feature compatibility version, even if sFCV("3.4") did not succeed cluster-wide.
In order to allow the config server primary to act as the cluster's source of truth for the current feature compatibility version, it should set its own state only after all shards have returned successfully from sFCV().