[SERVER-9906] Protecting against version skew between mongos and mongods Created: 11/Jun/13  Updated: 06/Dec/22  Resolved: 08/Mar/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Richard Kreuter (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-9776 Block migrations on hashed shardkeys ... Closed
Assigned Teams:
Sharding
Participants:

 Description   

As features get added to sharding, there can be bad results if somebody uses an old mongos with a cluster that's using newer features. For example, mongos pre-v2.4 doesn't know about hashed sharding, and weird things ensue if you use an old mongos with a hashed-sharded collection (e.g., inserts into the wrong shards). For another example, I'd imagine that a v2.0 mongos couldn't honor the v2.2 shard tags & tag ranges.

Although this falls into the user-error category of mistake (since we tell people to upgrade mongos first), it's easy to make mistakes here. We should guard against it, e.g., by having mongos include its version number in the arguments to setShardVersion and having mongod reject the command from sufficiently old mongoses.



 Comments   
Comment by Gregory McKeon (Inactive) [ 08/Mar/18 ]

We believe this issue has been resolved by the introduction of FCV and wire protocol version checks.

Comment by Greg Studer [ 02/May/14 ]

Since 2.4, config servers store a version number which mongos checks on startup to ensure that mongos won't start in a cluster it's too old to communicate with. 2.4 mongoses shouldn't start in 2.6 clusters, and 2.6 in 2.8 clusters, moving forward.

There's a separate issue with old mongods getting restarted in clusters at older versions, but mongos should be able to handle this cleanly. Ideally mongods would know about the config server immediately and fail to start if they're too old.

Generated at Thu Feb 08 03:21:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.