Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-26264

Make 3.2 mongos fail gracefully on startup when cluster is featureCompatibilityVersion("3.4")

    • Fully Compatible
    • ALL
    • Query 2016-10-10

      In SERVER-25158, we bumped the configsvr mode number in isMaster when the config server has featureCompatibiliityVersion "3.4". This prevents a 3.2 mongos from starting up against a FCV("3.4") cluster. Existing versions of mongos will get stuck in an infinite loop during sharding initialization as they attempt to connect to the config server replica set:

      https://github.com/mongodb/mongo/blob/r3.2.9/src/mongo/s/sharding_initialization.cpp#L185-L213

      While looping, the mongos will repeatedly log messages such as the following:

      2016-09-22T11:50:42.012-0400 W NETWORK  [mongosMain] No primary detected for set test-configRS
      2016-09-22T11:50:42.012-0400 I NETWORK  [mongosMain] All nodes for set test-configRS are down. This has happened for 5 checks in a row. Polling will stop after 25 more failed checks
      ...
      2016-09-22T11:50:42.513-0400 D -        [mongosMain] User Assertion: 28785:Unrecognized configsvr version number: 2. Expected either 0 or 1
      2016-09-22T11:50:42.514-0400 D -        [replSetDistLockPinger] User Assertion: 28785:Unrecognized configsvr version number: 2. Expected either 0 or 1
      

      Instead, the mongos process should quickly exit with a non-zero exit code and a useful error message, without ever making its routing service available. The error message should display a "MustUpgrade" error code and should link to the documentation for the 3.2=>3.4 upgrade process.

            Assignee:
            david.storch@mongodb.com David Storch
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: