The following scenario causes the server to stop accepting sessions.
- the driver creates logical sessions implicitly assuming the server supports it. Per offline chat with behackett the driver implicitly starts a session on the server iff the isMaster has a logicalSessionTimeoutMinutes set (https://github.com/mongodb/specifications/blob/master/source/sessions/driver-sessions.rst) and mongos 3.6 unconditionally returns that value in isMaster because it has no concept of FCV
- the mongos passes the command to mongod
- mongod creates the session in the cache but fails to add it to a collection because it does not have the config.systme.sessions collection with FCV 3.4
- without config.sessions.collection sessions are not expired and eventually hit the max of the activeSessionsCount = 1,000,000
Suggested Fix
The 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.
- every refreshSessions SessionsCollection needs to detect if the sessions collection exists and set the corresponding member
- add a method to LogicalSessionsCache::hasSessionsTable that retruns SessionsCollection::hasSessionsTable
- run LogicalSessionsCache::refreshNow on startup
- add logicalSessionTimeoutMinutes to isMaster if (FCV ==3.6) && LogicalSessionsCache::hasSessionsTable()
- reject explicit sessions operations if !LogicalSessionsCache::hasSessionsTable()
FCV update 3.6 to 3.4
- please read
SERVER-36104for guidelines
- depends on
-
SERVER-33763 3.6 drivers fail to communicate with 3.6 sharded clusters running at FCV 3.4
- Closed
-
SERVER-36104 LogicalSessions should destroy cache on setting FCV from 3.6 to 3.4
- Closed
- related to
-
MONGOID-5113 Fix session specs on 3.6 sharded cluster topology
- Closed