I'm coming from mLab and I'm used to having an option in my backup strategy that includes a mongodump backup as well as what Atlas calls a CPS (cloud provider snapshot). The latter is actually a snapshot of the database directory at the filesystem level, which is great for instant restores within Atlas (same or different cluster). However, the mongodump backup (from mLab as an example) allows me to backup on a regular schedule and download those backups for restores locally and elsewhere outside of Atlas.

Yes, I can run mongodump operations myself from a system outside of Atlas, but having those mongodump archives available within a rolling window is really great to quickly grab a backup and examine offline or in another environment entirely, with no additional management or systems from me to do so.

In Performance Advisor, I can see sample queries for each index suggestion.
They are formatted "nicely" for human viewing, but to actually investigate it, one would want to copy it as valid mongodb json, and run it with explain or analyze it in compass, or even just run it in a console to see how long it runs before and after the index addition.
However, there is no way of doing that, and I have multiple times "translated" the good looking ui to a mongo query so I could run it elsewhere.
This is a tedious and annoying thing (especially when you need to handle dates....).
Since you already have the data but chose to display/format it in a "nice" way, you also have the json behind it so please just let me copy it as json (with the proper ObjectId and ISODate or new Date() around ids and dates.

Thank you.

Hi, we have tried BETA of Autoscaling feature and we have some thoughts how to make it better. In its current setup its not really suitable for our production workloads. Here are some thoughts how to make it better:

1. Define separate scaling steps
   At them moment the scaling step is always 1. Going from M10 -> M20 which is not really suitable for burst loads where going one step up might not be enough. Same goes for rapid scaling down

Example:
Scale range = M10 - M50
Scale step up 4 = (M10 -> M50)
Scale step down 2 = (M50 -> M30 -> M10)

1. Define custom timescale
   It seems that current setup is to start scaling down after 72h, and then repeat every 24h.
   Our system can be scaled down much more rapidly, when our burst load goes away its done for a few days, we know we can start scaling down after 12h and repeat every 6h.
   With current setup it will take 6 days to scale down from M50 -> M10.




2. Define custom scaling metrics and thresholds
   It seems that current system is not taking N of connected clients as a scaling metric.



3. when connecting from cloud functions its easy to have a lot of connections which are not draining CPU or memory, when we are scaled down to M10 that limit is only 200


4. additionally we would like to scale up when our CPU limit is >50% which is not possible ATM

Nice to have:
4. Time based scaling events
scale up/down at specified time & day, useful for scaling up DEV/Research environments within working hours

PS: writing a long post in this form is terrible

This is a request to add support for the Token Groups LDAP attribute included in Active Directory’s LDAP implementation:

   <a rel="nofollow noreferrer" href="https://docs.microsoft.com/en-us/windows/win32/adschema/a-tokengroups">https://docs.microsoft.com/en-us/windows/win32/adschema/a-tokengroups</a>

Currently Atlas/Mongo only supports looking up group membership from queries against the user object in LDAP (typically by looking at the “memberOf” attribute). This attribute does not include groups to which a user is a member via nested groups (being in a group that is also a member of another group). An LDAP filter can be added to the user group lookup which uses recursive filters to find all groups, however, that approach has the following problems:

• Recursive lookups are slow


• Recursive lookups include non-security groups (such as email distribution groups)

TokenGroups is a virtual LDAP attribute found on AD groups (not users) that is server-side optimized and only includes security groups. However, the TokenGroups attribute cannot simply be queried with an LDAP filter. The TokenGroups attribute can only be retrieved from base-level searches and returns a list (LDAP array) of SIDs.

If you are interested in code examples of how to implement Token Groups the “Active Directory” plugin for Jenkins implements this feature.

When we get email notifications of upcoming maintenances, it doesn't specify if the update is "urgent" or "low". When we received our last notice, it was 3 days out. If it's urgent, then we understand the short time frame around the notice. However, if it's a lower priority update, I would hope we could configure how far out we are aware of the maintenance or at a minimum get notified 2 weeks prior so we can communicate to our end users.

Additional information around what the maintenance is for would be appreciated as well. Something along the lines of "Patching to 4.0.14" or "OS level updates". In general, we are in the dark in regards to what is being updated.