389 results found
When creating large new clusters sometimes Atlas does not have enough resources available from the cloud provider. When this happens a restore or cluster change fails without reporting what the actual issue is.
Solution: Verify available capacity and issue a warning or error if it is possible that the operation will fail & recommend opening a support ticket (or have a dialog to automatically do so listing the details)3 votes
Some situations require multiple private endpoints (using the Private Link service) to be created per region. This is not currently supported for multi-region replica sets.
One scenario is especially for when there is a shared VPC/VNet for initial transit from on-prem to cloud plus another VPC/VNet for an application. Both of those VPC/VNets would want a Private Endpoint to connect directly to the Atlas cluster. Even if it is possible (sometimes is not), routing traffic via multiple VPC/VNets would mean 3 hops to Atlas from on-prem2 votes
Enable SNMP setup on Atlas Resources.1 vote
Please see details in https://support.mongodb.com/case/006824802 votes
Using the Invoices API to aggregate cluster costs by label involves cross-referencing the Cluster API. Including cluster label information as part of the Invoices response would eliminate this extra step.3 votes
Please allow us to kill user threads on Mongo secondaries. Sometimes we have long running queries on secondaries and need to kill those threads but can't do anything about it since we don't have admin privileges to kill threads.
Also please add the ability to manually restart secondaries, not just failover the primary.
Allow the "SET GLOBAL mongodbmaxvarcharlength = n" to be permanent after a Mongosqld restart. Currently, the setting is ephmeral and must be set everytime the mongosqld daemon is restarted. Currently, our production environment mongosqld can restart without our knowledge at anytime. This results in the mongodbmaxvarharlength variable being reset to zero, which can lead to a production outage. Is there anyway this can be automated, maybe through database trigger?26 votes
A field indicating whether MFA is on for organization users (i.e. on https://docs.atlas.mongodb.com/reference/api/organization-users-get-all-users) would be extremely useful!2 votes
When we upgrade MongoDB there is the possibility that orphaned collections that need to be deleted can prevent the upgrade from completing.
It would make sense for Atlas to include a proactive utility that searched a customers sharded cluster for orphaned docs and gave them the option to clean up the orphaned docs ahead of a major version upgrade.1 vote
To be able to change and read Organizational Settings in an automated matter, support for Organizational Settings should be added to the Mongo Atlas API.4 votes
Atlas should be able to throttle IO in a way that does not allow excessive IO to degrade a node or take a node offline. Current functionality has no defense against a high IO data job other than to allow a node to fail.1 vote
Compacting of a collection directly from the MongoDB Atlas website UI.
No need to run CLI commands and changing primary database.
Making regular maintenance easier.6 votes
Would it be possible to be able to set up governance rules at the organization level in order to control certain configuration elements.
Control authorized providers and regions for an organization to prevent creation of cluster in unauthorized regions. (We must keep the data in Canada for some of our databases)
Check the allowed IP (IP Access List) addresses
Disable the use of SCRAMS accounts for database access.
Control the "Data Explorer" functionality at the organization level to prevent its activation at the project level.1 vote
Would it be possible to have a feature to redirect activity logs from ATLAS to a MongoDB cluster.
The idea is to be able to easily retrieve these logs with Kafka Connect and also to be able to easily query in these logs.
One could configure the redirection of activities at the organization and projects level by providing the Atlas cluster to use and the access accounts.
- Project: "Activity Feed"
- - Cluster: "Activity Feed Cluster"
- - DB: "Atlas Activities by organization"
- - - Collection: "Activities by project"1 vote
Currently the Atlas UI only presents options for how many shards a cluster can have.
Putting in a suggestion to perhaps allow similar functionality / features to Cloud Manager's shard management as shown : https://docs.cloudmanager.mongodb.com/tutorial/manage-data-sharding/#manage-sharded-collections3 votes
It would be great if Atlas provided support for hidden, priority 0 delayed replicas. For workloads that do not need real time data or situations where data recovery is needed, a delayed replica would be the fastest way to mitigate both of those scenarios.2 votes
Right now it is difficult to rename and move databases and collections without downloading and re-uploading them.
Please enable this critical functionality as it's very common to need this when administering data.2 votes
It could be very interresting to be able to setup the retention of the events by organisation, projets and clusters. Actually I understand that this value is 30 days. So it to short for us, so we need to download the activities logs and it difficult to seach in files after that.1 vote
Events (in the perimeter: organization, projects, cluster) are useful for monitoring activities. But it would be very useful to be able to set the alarm on these events. The goal is to be informed when certain actions occur.
The best is to be able to have a configuration control policy. Especially to control security, network configuration, etc ...
- Be able to avoid the use of user scram.
- Be able to avoid using unauthorized IP addresses
- Be able to avoid changing the configuration of access to database data (DataExplorer) from the Atlas portal2 votes
Right now I am running the MongoDB cluster on 3.6. Now I want to upgrade this cluster to 4.0. But when I want again to revert back to 3.6 I have no option to downgrade.
Use case :
Right now our production is running on 3.6, when we upgrade this to 4.0 and if we face any major issues on prod, then we have no option to get back to old version 3.6.
Without this option we cannot move our production to 4.0.1 vote
- Don't see your idea?