[SERVER-14504] Mongos ismaster should return valid wire version range across all shards Created: 08/Jul/14  Updated: 10/Dec/14  Resolved: 09/Jul/14

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

Type: Improvement Priority: Major - P3
Reporter: David Golden Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

Currently, drivers determine cluster capabilities based on the mongos ismaster result. When the mongos has a different version than one or more shards, drivers can issue commands based on the mongos reported wire protocol version that will fail when distributed to shards that don't support it.

If a mongos ismaster synthesized wire versions across shards and returned the lowest maxWireVersion and highest minWireVersion between itself and the primary of each shard, that would allow drivers to limit operations to things that will succeed when distributed to shards.



 Comments   
Comment by David Golden [ 09/Jul/14 ]

I don't think "works as designed" is the right answer here.

I understand that mongos is responsible for emulation, but in some cases, it can't emulate things (e.g. aggregation cursors). Yet, by reporting a wire protocol range, mongos advertises feature support that it can't deliver. Are you saying that was an intentional design decision?

I think, the "guarantee" issue is a red herring – even if stale until the next driver heartbeat, an aggregated range would be better than nothing, allowing end-user code to detect capabilities and adjust accordingly.

Comment by David Golden [ 09/Jul/14 ]

I don't think "works as designed" is the right answer here.

I understand that mongos is responsible for emulation, but in some cases, it can't emulate things (e.g. aggregation cursors). Yet, by reporting a wire protocol range, mongos advertises feature support that it can't deliver. Are you saying that was an intentional design decision?

I think, the "guarantee" issue is a red herring – even if stale until the next driver heartbeat, an aggregated range would be better than nothing, allowing end-user code to detect capabilities and adjust accordingly.

Comment by Greg Studer [ 09/Jul/14 ]

Distributing operations to shards is more complex than this - currently mongos is responsible for emulation when required. Also there's no guarantee that the result from any aggregated isMaster will be correct in the future.

There is a separate discussion to be had about upgrade procedures and whether mongos is the right place to start an upgrade, but probably not here.

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