[SERVER-31789] How will mongos report logicalSessionTimeoutMinutes? Created: 01/Nov/17  Updated: 02/Nov/17  Resolved: 02/Nov/17

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

Type: Question Priority: Major - P3
Reporter: Jeremy Mikola Assignee: Samantha Ritter (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-28916 Make mongos automatically retry faile... Closed
is related to SERVER-31738 fcv34 should suppress logicalSessionT... Closed
Participants:

 Description   

I'm curious how SERVER-31738 will interact with mongos. If all shards are feature compatibility mode 3.6, I suppose we can expect mongos' isMaster response to include logicalSessionTimeoutMinutes, but what if two shards are 3.6 mode and one shard is not? Does the introduction of a new shard lacking sessions break sessions for the entire cluster? Alternatively, if only one of three shards does not support sessions, is mongos still capable of retrying writes to the shards that do have support?



 Comments   
Comment by Jeremy Mikola [ 02/Nov/17 ]

Thanks. I think that clears up our original questions.

Comment by Kaloian Manassiev [ 02/Nov/17 ]

Correct, we will get a batch write reply with {ok:true} and a writeError entry containing some kind of "NotSupported" error.

Comment by Samantha Ritter (Inactive) [ 02/Nov/17 ]

Kal would know better how the fan-out works, but that is how I believe it would work, that you would get back an error from the individual writes that were directed to the FCV 3.4 nodes. I have not tried this, though (nor could I until SERVER-31777 is done)

Comment by Jeremy Mikola [ 02/Nov/17 ]

samantha.ritter: That's correct. In such an edge case, I would expect FCV 3.6 mongos to send along write commands with lsid and txnNumber to each targeted shard. Any FCV 3.4 mongods will then raise an error (per SERVER-31777), and mongos may report that a subset of writes failed in its response to the driver (akin to Kal's comment in SPEC-982 about mongos relaying a NotMaster or NetworkError to the driver). Is that accurate?

Comment by Samantha Ritter (Inactive) [ 02/Nov/17 ]

jmikola I think your question here is "What happens to the logicalSessionTimeoutMinutes field reported by mongos when we are running in an FCV 3.6 cluster, but there are shards with FCV 3.4?" Is that correct? With the caveat that we could only be in this state in very particular cases.

Comment by Jeremy Mikola [ 02/Nov/17 ]

Based on discussion with kaloian.manassiev this morning, I was told that mongos will decide to report logicalSessionTimeoutMinutes based only the cluster's FCV configuration. This question pertains to an edge case if a 3.6 standalone is added as a shard, or an active replica set shard has its FCV downgraded from 3.6 to 3.4 (assuming either of those is even possible).

Note: Since a 3.6 mongos cannot even communicate with a 3.4 mongod binary, there is no concern that a FCV 3.6 cluster might include mongods with an older binary version.

Comment by Jeremy Mikola [ 02/Nov/17 ]

This might also relate to my question in SERVER-28916, if it's possible that sessions and retryable writes are only supported by a subset of shards in the cluster.

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