[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: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Sprint: | Sharding 2020-05-04, Sharding 2020-05-18, Sharding 2020-06-01, Sharding 2020-06-15 | ||||||||
| Participants: | |||||||||
| Case: | (copied to CRM) | ||||||||
| 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 |
| 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. |