In general the upgrade order for a sharded cluster is config servers first, then shards, then mongoses. Thus it is illegal for a mongos from the current version to ever talk to a mongod from the previous version. To enforce this, we need to prevent new mongoses from processing an addShard request that will result in an old mongod being added to the cluster. For the 3.2->3.4 upgrade we handled this in SERVER-25514, but that approach won't work for the 3.4->3.6 upgrade.
- related to
-
SERVER-25514 prevent 3.4 config from adding a 3.2 shard during _configsvrAddShard
-
- Closed
-