[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. |