[SERVER-37658] Mongos 3.6 requires min and max wire version to be 6 (6,6) Created: 18/Oct/18  Updated: 27/Oct/23  Resolved: 18/Oct/18

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: 3.6.7
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Rob Manning Assignee: Kaloian Manassiev
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Steps To Reproduce:
  1. Perform a rolling downgrade (config replSet, each shard replSet, then finally mongos nodes).  
  2. Before downgrading the mongos nodes, connect with the shell and note that the cluster is inaccessible.
  3. View the mongos.log and note the aforementioned log message.
  4. Downgrade the mongos and reconnect with the shell.  Note that the cluster is now accessible.
Participants:

 Description   

When performing a rolling downgrade on a version 3.6.7 cluster to version 3.4, once the config servers and shards have all been downgraded, the remaining version 3.6 mongos nodes can no longer connect to the cluster.  This can be seen in the mongos.log:

<timestamp> W NETWORK [UserCacheInvalidator] remote host has incompatible wire version: IncompatibleServerVersion: Server min and max wire version are incompatible (0,5) with client min wire version (6,6).

However, when connecting to a version 3.6.7 mongod and running the command db.isMaster(), the resulting document shows "minWireVersion" : 0, "maxWireVersion" : 6.

This makes it impossible to perform a rolling downgrade from 3.6.7 to 3.4.x without taking an outage, as all mongos nodes become unusable from the time that the config servers are downgraded until the time that at least one mongos is downgraded.



 Comments   
Comment by Kaloian Manassiev [ 18/Oct/18 ]

Yes, for all versions from 3.2 onwards the order of downgrade is first mongos, then shards, then config server (inverse to the order for upgrade).

Comment by Rob Manning [ 18/Oct/18 ]

Ahhhh!  So the upgrade and downgrade procedures differ with regard to the order of different types of nodes (particularly mongos). That's unfortunate for our internal update automation.  Is this also the case for downgrades from 4.0 to 3.6?

Comment by Kaloian Manassiev [ 18/Oct/18 ]

Hi wideningartist9,

What you are experiencing is expected, because 3.6 mongos is not allowed to talk to 3.4 shards/config server.

The downgrade instructions here state that the first thing, which needs to be downgraded after FCV is set to 3.4 are the mongos instances.

Hope this helps.

-Kal.

Generated at Thu Feb 08 04:46:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.