Atlas
- A brief description of what you are looking to do
- How you think this will help
- Why this matters to you
473 results found
-
Manage Feature Compatibility Version (FCV) flag separately from version upgrade
When performing a major server version upgrade (e.g. to MongoDB 7.0), Atlas automatically set the Feature Compatibility Version (FCV) flag to the same version.
We would like to see this be a two-step, i.e.
1. When upgrading to 7.0, Atlas keeps the FCV pinned at "6.0"
2. 1~2 weeks after upgrading, Atlas reminds us increase the FCV to "7.0", i.e. once we've seen it running stable.We had a major production-outage issue in upgrading to MongoDB 7.0 and because of the current Atlas FCV behavior we could not downgrade back to 6.0.
We understand that some users don't care about…
3 votes -
Retrieve latest/max oplog timestamp via the Atlas Administration API
At the moment the latest/max oplog timestamp can be retrieved via the Atlas UI in the backups section for point in time restores. This feedback post is to make this information available as part of the atlas administration api.
For example, in the UI it states:
You can only restore up to this oplog timestamp: 1692580549 and this increment: 1.
Would be good to have this value available to be retrieved via the API for restores requiring oplog timestamp values in this format.
3 votes -
Enable database users separate read/write permissions based on cluster
We have multiple clusters in the same project, and we need to limit write access to certain CLUSTERS while leaving read only access to any other cluster. The problem is that we cannot do this by DATABASE name as there are many of them, as well as dynamically addition of new ones in clusters, so it will become obsolete and very hard to maintain.
Trying to use the restriction does not help as it limits all access, including read only, to those clusters.
What we'd like to see is that we can limit write access by cluster (not database/collection) and…3 votes -
Remove the requirement to have an API Access List CIDR before being able to manage backup schedules
The issue is described in this github issue, specifically in the linked comment: https://github.com/mongodb/terraform-provider-mongodbatlas/issues/222#issuecomment-855905952
Here is the requirement as described in the API docs: Remove All Cloud Backup Schedules
Removes all cloud backup schedules for the specified cluster. "This schedule defines when MongoDB Cloud takes scheduled snapshots and how long it stores those snapshots. To use this resource, the requesting API Key must have the Project Atlas Admin role and an entry for the project access list."
https://www.mongodb.com/docs/atlas/reference/api-resources-spec/#tag/Cloud-Backups/operation/deleteAllBackupSchedulesOur request is that the requirement to have an API Access List to manage backup policies be removed.
At the very least,…
3 votes -
Suggestion to make the Organization Role Mappings page easier to navigate to
Make Organization Role Mappings page in the Federation Management App quicker to navigate to. Currently the quickest way is to click the "Create Role Mapping" from the Overview page under "Optional: Set Up Advanced Settings" and then click Cancel.
If the "Optional: Set Up Advanced Settings" box is not longer available in the Overview page, you'll have to click the Organization tab from the side navigation bar > [Organization Name] > Create Role Mapping > Cancel in order to reach the Organization Role Mappings page.
3 votes -
MongoDB Connection Pool Proxy
Currently there is no Connection Pool proxy supported by MongoDB.
With the ever increasing use of serverless and containers, clusters will need to be over provisioned in order to account for the increased connection counts.
A better solution would be a Connection Pool proxy allowing for a many-to-one relation for connections to MongoDB.
In the case of Lambda, this would reduce the number of Zombie connections (Connections that have been terminated on the Lambda side but are still open on the server side.)
3 votes -
Option to deploy the databases with pinned version.
Atlas by default picks the latest patch when we create the databases for any major version. It would be helpful if the customers can choose and control the minor version of the databases(including patch version) when we deploy the cluster. For example: We want to deploy the databases with 4.2.19 but the Atlas is automatically creating 4.2.22
This will help us identify any application dependencies on any particular patch version during our migration to Atlas, also this will help us test the patch versions in dev/lower environments before we promote the version to production.
This feature is important for us…
3 votes -
Atlas shards with different clusters tiers
For solutions of hot and cold storage, there is at least 2 options:
- Online archiving
- Hot and cold cluster (using a trigger and datalake)
But these solutions have limitations (https://www.mongodb.com/docs/datalake/limitations/)There is another solution: using sharding.
We can set shards like so:
1 shard: Data from the last 2 months -> Hot data
1 shard: Data between 2 and 24 months -> Warm data
1 shard: Data more than 24 months -> Cold dataThe usage pattern: 95% of the accesses/queries go to shard with the hot data.
On Atlas, we need to set the same…3 votes -
Test maintenance effects
While Atlas provides the 'test failover' feature, this only takes effect on the primary of each shard. Customers who run large sharded clusters on Atlas require testing the effects of a full maintenance patch that would restart all mongod's and mongos's, config servers, etc. This feature is a request to improve the chaos engineering features of Atlas.
At present, customers are being advised to change the TLS version of the cluster which could force restarts of all mongod's, mongos's and config servers. While this may be acceptable in non-production environments, it is unlikely in production environments.
I believe there's an…
3 votes -
disabling mongo user
Instead of completely removing a Mongo database user, its better if there is option to disable user so that if there is any untoward incident we can enable it back. After observing for some time, we can delete/disable the user based on organization requirements. Its useful in some cases like mongo db user returned to same department after some time .
3 votes -
Support NVMe for Atlas Azure
Support NVMe disk for MongoDB Atlas Azure.
3 votes -
Copy/Duplicate Cluster configuration
It would be really useful to create a new cluster based on an existing configuration.
Snapshots are supposed to be loaded into clusters of the same configuration, but having to set up the configuration manually is prone to human error. Having an option to copy the cluster configuration would be helpful.
Support suggested the following workarounds, but the option should really exist in the UX, given that snapshots can be taken and loaded in the UX.
- use the API to create all clusters so that the config exists in code
- use terraform to create clusters3 votes -
Feedback and public roadmap.
I have voted and written since 2020 several improvement ideas for your platform.
Being a client for a major insurance company, I'm disappointed to see that for several suggestions dating back more than 12 months, it doesn't even seem to have been looked at by your team.
It would be more than interesting to have an idea for your roadmap as well as a dynamic management of the catalog of ideas (feedback) maintained by your customers.
I consider this a lack of respect for your users and customers.
Some examples:
https://feedback.mongodb.com/forums/924145-atlas/suggestions/40638277-atlas-backup-to-second-region
https://feedback.mongodb.com/forums/924145-atlas/suggestions/43289796-max-database-users-not-visible
https://feedback.mongodb.com/forums/924145-atlas/suggestions/42163234-authentication-on-azure-iam
3 votes -
Warm up cache automatically when there is any server/node restart events
Usually it takes hour or so for the cache to warm up depending on the data size when an server restart scenario occurs ( increasing the tier / storage etc). And there are alternatives like running cache warm up queries to bring the nodes up to speed .
However if this cache warm up should be inherent and automatic for the server restart scenarios .
3 votes -
Add the In-Memory Storage Engine to Atlas
Enable the use of the in-memory storage engine in atlas shards. That way atlas users can get the same level of functionality as enterprise. Atlas is a great platform, but not being able to use an in-memory storage engine replica set in a shard is a huge letdown (at least for me).
3 votes -
Support Linode as a cloud service
Linode is a widely used cloud provider between developers that do not like the outrageous interface & costs of the main providers (Google, Atlas, AWS). Linode has free in-network bandwidth as well, making for private connections to be much cheaper.
3 votes -
Add a simple log filter in the Atlas log API call
In the Atlas log API call, add a new Request Query Parameter which allow people to set a phase or string, to avoid downloading log lines including this phase or string.
So people don't have to download large quantity of log messages that they don't need.
For example the the NETWORK log message between replica-set members.
3 votes -
Improve handling of ROLLBACK state
Recently we had a member of a replica set in a sharded cluster enter
ROLLBACK
state. We just happened to notice it in an automated email sent by Atlas about primary elections which showed one of the members inROLLBACK
state.Fortunately for us the writes which had been reverted were not critical and we were fine with that. However, this could have resulted in serious data loss which could have gone unnoticed until a customer reached out to us.
The handling of a situation like this one should have been much better and more user friendly. We should have…
3 votes -
Access key expiration date
We would like to have option set expiration date time while creating API access keys and also ability to check expiration options through API.
3 votes -
Preserve Oplog upon storage downgrade in Azure
Oplog was wiped out upon storage downgrade from 128Gb -> 16Gb, even though the database size incl. oplog was less than 2-3Gb.
Please change the downgrade procedure to NOT wipe out the oplog.
This was tested/experienced on Azure.
3 votes
- Don't see your idea?