[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: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
I'm curious how |
| 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 |
| 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 |
| 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. |