[SERVER-30341] Add FCV to isMaster Created: 26/Jul/17  Updated: 15/Aug/17  Resolved: 14/Aug/17

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

Type: Task Priority: Major - P3
Reporter: Misha Tyulenev Assignee: Tess Avitabile (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-30624 Add featureCompatibilityVersion to se... Closed
Sprint: Query 2017-07-31
Participants:

 Description   

Currently there is no way to tell what is the version of the server connected to a mongos.
this makes impossible to make a decision if mongos needs to wait for keys from config server which will generate them only fin FCV 3.6.

Suggested implementation: It will be easy to get from the FCV of config shard from the isMaster response in mongos if this field would be there.



 Comments   
Comment by Andy Schwerin [ 15/Aug/17 ]

To close the loop, I was reluctant to add fcv to ismaster without some consideration because we already have other version checking techniques using wire version in ismaster. Wire version isn't really meeting our needs (see driver feature selection logic), but I don't know if fcv would, either. Feature availability checking is in need of a broader review, and until we do that, I want us to avoid adding new ways.

If Misha had been truly stuck, I'd reconsider.

Comment by Tess Avitabile (Inactive) [ 14/Aug/17 ]

Thanks. In that case, I will close this as won't fix, since I think the best solution for SERVER-30624 would be to add the featureCompatibilityVersion to the serverStatus output.

Comment by Misha Tyulenev [ 14/Aug/17 ]

tess.avitabile that's correct i implemented the workaround on mongos.

Comment by Tess Avitabile (Inactive) [ 14/Aug/17 ]

misha.tyulenev, it sounds like you have a work-around for this issue. Is that correct?

schwerin, I'm curious why you think it is not a good idea to include featureCompatibilityVersion in the isMaster response. There is a request in SERVER-30624 to make it possible to read the featureCompatibilityVersion without the getParameter privilege. One option is to include it in the serverStatus output. That seems very reasonable, since we include the binary version in the serverStatus output. Another is to include it in the isMaster response. I would recommend that if it is a requirement for the Sharding team.

Comment by Misha Tyulenev [ 26/Jul/17 ]

Sure, I made changes to add internalClient to all isMaster requests sent by RSM so it detects the change (SERVER-30249)
it works but it looks a little opaque since the isMaster returns minWireVersion == maxWireVersion only for internal client and when FSV = 3.6 (https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/replication_info.cpp#L360. so the client the code needs to check that minWireVersion == maxWireVersion.
the core issue is that FCV 3.4 does not mean that maxWireVersion is equivalent to FCV 3.4 features, wireVersion is a feature of the binary of the sender. Hence we need to use those indirect detection for finding out FSV of the sender.

Comment by Andy Schwerin [ 26/Jul/17 ]

I'd prefer to stick to using the wire protocol version.

Comment by Tess Avitabile (Inactive) [ 26/Jul/17 ]

The first time a mongos connects to a mongod, it can determine the FCV. The first isMaster command the mongos sends to the mongod includes the internalClient field. When that is present, if the mongod has FCV=3.6, it will return min wire version = max wire version. We could add internalClient to all isMaster commands sent by the mongos, so that it can detect changes in the FCV using the wire version range. Or we could add the FCV to the isMaster response.

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