[SERVER-39052] Reading and writing FCV is asymmetric in sharded clusters Created: 16/Jan/19 Updated: 26/Oct/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.0.3 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Oleg Pudeyev (Inactive) | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ShardingRoughEdges, oldshardingemea, sharding-common-backlog, shardingemea-qw | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||
| Participants: | |||||||||
| Story Points: | 2 | ||||||||
| Description |
|
https://docs.mongodb.com/manual/reference/command/setFeatureCompatibilityVersion/ states that setting FCV is done on a mongos, but reading the FCV back on a mongos is not allowed. Writing: > For a sharded cluster, run the command on a mongos instance. Reading: > The operation is undefined on the mongos instances. For a sharded cluster that has access control enabled, to run the command against a member of the shard replica set, you must connect to the member as a shard local user. Why is mongos able to write FCV but not read it back? |
| Comments |
| Comment by Kaloian Manassiev [ 18/Jan/19 ] |
|
You are right that this is a minor nuisance that contributes to the behavioural difference between sharded and unsharded systems. I am putting it on the sharding team's Backlog with a low priority and a proposed way to fix it. tl;dr The only way to fix this would be to specialise the getParameter command on the routers and shards to ask the config server for the FCV parameter, if the nodes are sharding components. |