[SERVER-44474] Ensure config.sessions collection can be safely managed independent of ttlMonitorEnabled setting Created: 07/Nov/19  Updated: 06/Dec/22  Resolved: 01/Feb/21

Status: Closed
Project: Core Server
Component/s: TTL
Affects Version/s: 4.0.13, 4.2.1
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Eric Sedor Assignee: Backlog - Storage Execution Team
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to DOCS-13741 Augment ttlMonitorEnabled server para... Closed
Assigned Teams:
Storage Execution
Sprint: Sharding 2020-05-04, Sharding 2020-05-18, Sharding 2020-06-01, Sharding 2020-06-15
Participants:
Case:

 Description   

Currently, server-side session management has a dependency on a TTL index in the config.sessions collection. Is it possible to ensure users can safely set ttlMonitorEnabled=false without affecting session management?



 Comments   
Comment by Eric Milkie [ 01/Jul/20 ]

I filed DOCS-13741 to change the documentation to avoid future routine use of ttlMonitorEnabled. The functionality of disabling TTL deletes must remain accessible from outside the server to support certain procedures like backup, but should otherwise not be used routinely to reduce load on a server. We'd like to improve the performance of deletes instead, for such use cases.

Comment by Daniel Gottlieb (Inactive) [ 19/May/20 ]

john.morales did you find whether this would impact backup or automation?

Comment by Matthew Saltz (Inactive) [ 19/May/20 ]

daniel.gottlieb Have you heard anything from Backup?

eric.sedor Any thoughts on whether/how far this needs to be backported?

Comment by Daniel Gottlieb (Inactive) [ 12/May/20 ]

I know HEAD based backups (v4.0 and earlier?) disable the ttl thread. I can't recall if that was because there was a time where bringing up a replica set in standalone would let the TTL run wild (still the case?), or some other reason. Looping in Backup (with a message because at-mentions aren't loading the right people).

How far back did we want to backport this?

Comment by Sheeri Cabral (Inactive) [ 13/Dec/19 ]

Hi Kelsey,

I agree that we should not recommend turning off ttlMonitorEnabled while the config.sessions table is coupled to standard TTL indexes. I did a bit of searching to figure out why people would use this; seems that it's been suggested that the monitor running every minute could cause additional load. It's unclear if there's additional load when there are no TTL indexes. 

I'd prefer to decouple so that config.sessions pares down entries regardless of the status of ttlMonitorEnabled. I do think it's important that people be able to disable TTL monitoring - there is a use cases where the monitoring is disabled during peak times, and another to disable it while doing a point-in-time recovery. Looping alyson.cabral in as well, as I think this needs higher visibility.

Comment by Kelsey Schubert [ 06/Dec/19 ]

ratika.gandhi, sheeri.cabral, brian.lane, I feel like this is a foot-gun that makes it impossible to recommend turning off ttlMonitorEnabled. We should have a plan for how to address this issue, and I'm struggling to see how part of that plan wouldn't include a server code change given that the coupling of TTL and config.sessions means ttlMonitorEnabled=false can lead almost directly to downtime.

I'd like to keep this ticket open until we have a plan to address this issue.

Comment by Bruce Lucas (Inactive) [ 06/Dec/19 ]

Alternatively, do we need to remove, deprecate, or ban under certain conditions turning off ttl monitoring?

Or would it be possible to change the implementation of ttlMonitoringEnabled so that it does not disable the ttl monitoring thread but only bypasses all but config.system.sessions?

Comment by Josef Ahmad [ 06/Dec/19 ]

Is there a DOCS to document the caveat (logical sessions reaping) when turning off ttlMonitorEnabled?

Comment by Ratika Gandhi [ 06/Dec/19 ]

Unfortunately, this is not feasible. 

Generated at Thu Feb 08 05:06:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.