[DOCS-8895] Make 3.2 mongos fail gracefully on startup when cluster is featureCompatibilityVersion("3.4") Created: 28/Sep/16  Updated: 02/Nov/16  Resolved: 27/Oct/16

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: 3.4.0, mongodb-3.4p1

Type: Task Priority: Critical - P2
Reporter: Emily Hall Assignee: Kay Kim (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-26264 Make 3.2 mongos fail gracefully on st... Closed
Participants:
Days since reply: 7 years, 16 weeks ago
Epic Link: 3.4: Sharding Updates

 Description   

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.



 Comments   
Comment by Kay Kim (Inactive) [ 27/Oct/16 ]

Am closing because I believe this is handled in the downgrade procedures where the prerequisite is to update FCV to "3.2" before we downgrade the binaries.

Also, FYI, the dochub link was enabled when we did the upgrade stuff.

Comment by David Storch [ 07/Oct/16 ]

pasette, I believe that work is tracked by DOCS-8328 and DOCS-8329.

Comment by Daniel Pasette (Inactive) [ 07/Oct/16 ]

Where is the main ticket for upgrade/downgrade documentation? I noticed today that the dochub link: http://dochub.mongodb.org/core/3.4-feature-compatibility is not yet enabled.

> db.createView(
...    "managementFeedback",
...    "survey",
...    [ { $project: { "management": "$feedback.management", department: 1 } } ]
... )
{
       	"ok" : 0,
       	"errmsg" : "Cannot create view when the featureCompatibilityVersion is 3.2. See http://dochub.mongodb.org/core/3.4-feature-compatibility.",
       	"code" : 115,
       	"codeName" : "CommandNotSupported"
}

Comment by David Storch [ 29/Sep/16 ]

emily.hall, this will be part of a larger effort to document the 3.2=>3.4 upgrade process and the 3.4=>3.2 downgrade process. The query team can help put something together, since we did a lot of the upgrade/downgrade related work in 3.3 development.

Generated at Thu Feb 08 07:57:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.