addShard should fail if shard's binary version < the cluster's featureCompatibilityVersion

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Done
    • Priority: Major - P3
    • 3.6.0-rc0
    • Affects Version/s: None
    • Component/s: Sharding
    • None
    • Fully Compatible
    • Sharding 2017-10-02, Sharding 2017-10-23
    • 0
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      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.

            Assignee:
            Esha Maharishi (Inactive)
            Reporter:
            Spencer Brody (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: