[SERVER-37631] Disable logical sessions if FCV is 3.4 Created: 15/Oct/18 Updated: 08/Jan/24 Resolved: 01/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.6.8 |
| Fix Version/s: | 3.6.9 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Misha Tyulenev | Assignee: | Misha Tyulenev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | SWCW | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Sprint: | Sharding 2018-10-22, Sharding 2018-11-05 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||
| Description |
|
The following scenario causes the server to stop accepting sessions.
Suggested FixThe gist of the fix is mongos should rely on sessions collection existence on the config server to return the logicalSessionTimeoutMinutes in isMaster and handling explicit sessions operations.
FCV update 3.6 to 3.4
|
| Comments |
| Comment by Githook User [ 19/Mar/19 ] |
|
Author: {'email': 'mbroadst@gmail.com', 'name': 'Matt Broadstone', 'username': 'mbroadst'}Message: test: fix sessions tests on 3.6 sharded clusters
|
| Comment by Githook User [ 19/Mar/19 ] |
|
Author: {'email': 'mbroadst@gmail.com', 'name': 'Matt Broadstone', 'username': 'mbroadst'}Message: test: fix sessions tests on 3.6 sharded clusters
|
| Comment by Matt Broadstone [ 18/Mar/19 ] |
|
I'm also seeing the same behavior when running integration tests for the node driver, is there any plan to correct this in future versions? |
| Comment by Shane Harvey [ 08/Feb/19 ] |
|
When starting 3.6.9/3.6.10 sharded clusters I had to make a change to mongo-orchestration to run the refreshLogicalSessionCacheNow command on the config server and again on each mongos in order for the mongoses to correctly report logicalSessionTimeoutMinutes in their isMaster responses. Without running refreshLogicalSessionCacheNow in this way, the mongoses only start reporting logicalSessionTimeoutMinutes 5 minutes after adding the shard. Is this working as designed? Why does is take 5 minutes for the cluster to decide it supports sessions? |
| Comment by Githook User [ 01/Nov/18 ] |
|
Author: {'name': 'Misha Tyulenev', 'email': 'misha@mongodb.com', 'username': 'mikety'}Message: |
| Comment by Misha Tyulenev [ 22/Oct/18 ] |
|
kaloian.manassiev thanks for the feedback: |
| Comment by Kaloian Manassiev [ 18/Oct/18 ] |
|
The approach sounds good, but I want to ask just a couple of clarifications. The logic that you are describing will only run on MongoS, right?
This will run before MongoS starts accepting connections, right? Otherwise at MongoS restart, a driver which happened to work might suddenly stop and/or have undesired side effects. If for some reason refreshNow fails we will not fail startup, right - just continue trying? Also, do we have precedent before that where we do reads from MongoS before opening the connections - maybe the ShardRegistry? Just asking because that would increase the MongoS startup time, but I think it is fine to do that. Just something to keep in mind with the overall push towards "less impactful restarts/upgrades".
MongoS doesn't have any concept of FCV. Do you mean that this would be the logic on the MongoD side? Because MongoD already has the first condition. |