Geoffrey
My feedback
155 results found
-
210 votes
Hi all – We are currently developing collection and database-level restores. We expect this feature to be released in CY2025, but will update here once it is launched.
An error occurred while saving the comment An error occurred while saving the comment Geoffrey
commented
Hello,
The Atlas portal/API offers the ability to restore a complete database instance from snapshot or restore point. However the scope of this restoration covers the entire instance.
It would be a great asset to be able to restore a simple database from snapshots (encrypted or not). Currently, restoring a database (not a cluster) is a heavy workload that requires outputting data to a local workstation.
Thanks.
Geoffrey
supported this idea
·
-
5 votesGeoffrey
supported this idea
·
An error occurred while saving the comment Geoffrey
commented
Hello MongoDB,
I totally agree with Ershad's request about the ability to select the source of the backup you want to restore.
This functionality is necessary to meet the requirements of the regulatory authorities governing our field.
I've already opened a support ticket on this subject (Case #01328025).
I hope to have this feature available very soon.
Best regards.
-
11 votes
An error occurred while saving the comment Geoffrey
commented
Samething for us. Actually we have 14 linked organisation and more than 42 projects to support more than 81 clusters.
We managed that with API Key and Terraform.
As a member of a infrastructre team, it can be very usefull to be able to have a master API key to manage that.
Geoffrey
supported this idea
·
-
51 votes
Hi everyone, we appreciate your patience and are happy to share that we've started working on this feature. We're targeting GA for Q2 (May-July) and will provide an update once it is launched. Thanks!
An error occurred while saving the comment Geoffrey
commented
Or Azure Storage...
Geoffrey
supported this idea
·
-
13 votes
An error occurred while saving the comment Geoffrey
commented
Hello MongoDB,
We made this request a long time ago. This problem is still relevant to us.
Currently, the only way to manage this is to create separate projects for each cluster. Obviously, we don't like this solution. It is already possible to limit users to a cluster, why not extend this ability to the custom role as well.
Thank you for considering our request.
We currently manage more than 71 MongoDB clusters in around 40 separate projects. Our projects allow us to segment by environment and business sector.
Thus, a business sector can use several MongoDB clusters. Each MongoDB cluster is dedicated to a separate application, which is why we would need to limit the security of "Custom Roles" to very specific clusters.
Thanks.
Geoffrey
shared this idea
·
-
28 votesGeoffrey
supported this idea
·
-
52 votes
Thank you all for your feedback!
We hear you loud and clear and are working on exposing these details in the next quarter.
Geoffrey
supported this idea
·
-
19 votesGeoffrey
supported this idea
·
-
20 votes
An error occurred while saving the comment Geoffrey
commented
Dear MongoDB team,
We have been using your powerful database management system for a while now and we truly appreciate the many benefits it offers.
However, we have found that the process of deploying and managing our MongoDB instances can be time-consuming and complex. We believe there is a significant opportunity to leverage automation to streamline these operations and enable us to focus on delivering value to our customers.
In light of this, we would like to request your assistance in automating our MongoDB deployments.
By working together, we can optimize our processes and significantly reduce the time and effort required to deploy and manage our MongoDB instances.
We are confident that together we can achieve greater efficiency, reliability, and scalability in our deployment processes.
We understand that automating such processes can be a complex undertaking, but we believe that with your great expertise and support we can achieve our goals. We look forward to your assistance and collaboration in building a solution that meets our specific needs.
Thank you for considering our request, and we look forward to hearing from you soon.
Best regards,
An error occurred while saving the comment Geoffrey
commented
Accurate timezone configuration is a crucial aspect when managing maintenance schedules for any project. Therefore, it is essential to be able to set the project's timezone so that scheduled maintenance windows are consistent with relevant time zones.
Precise maintenance scheduling reduces the potential impact on users or the overall system, ensuring that maintenance operations are carried out in a coordinated manner. To achieve this goal, it is important to configure the timezone accurately so that the maintenance team has a clear and precise calendar.
As a result, it is imperative to allow for easy and precise timezone configuration for each project, simplifying effective scheduling of maintenance windows and contributing to optimal project management.
Geoffrey
supported this idea
·
-
157 votesGeoffrey
supported this idea
·
-
8 votes
An error occurred while saving the comment Geoffrey
commented
Bonjour MongoDB,
We again had a problem with encryption at rest on one of our MongoDB Atlas clusters. After a rotation of the secret for access to the encryption keys, one of the nodes of a recluster did not go up. No alerts available in MongoDB Atlas to monitor this are available. We don't even have an event that indicates this problem to us.
We receive an email (which is not a good reliable monitoring method for us) from MongoDB informing us of the problem (ISSUE REFERENCE: PROACTIVE-57330).
We opened a support ticket after reading this message 24 days after receiving it. You must be able to monitor this type of incident via alerting in order to capture this type of problem as early as possible and avoid a production incident.
See our ticket for this occurrence of the problem.
An error occurred while saving the comment Geoffrey
commented
Hello MongoDB,
We have a problem last week with Encryption at rest. MongoDB was not able to reach our Key Manager on Azure even it was available. MongoDB decide to shutdown our cluster for 3 hours. Do you plan to prioritize this feature request. Dont have this can compromize the usage of MongoDB in production.
See ticket: 00859378: Encryption at rest using Key stored in KeyVault failed
Geoffrey
shared this idea
·
-
11 votes
An error occurred while saving the comment Geoffrey
commented
Hello MongoDB. It is not too late to commit this feature for availability in the next version of your drivers. We would be very happy to try it soon. :-)
Geoffrey
shared this idea
·
-
8 votes
An error occurred while saving the comment Geoffrey
commented
Hi Salman,
Sorry, I hadn't seen your question.
We have opened a ticket regarding this issue already. See https://support.mongodb.com/case/01056829
In fact, an example scenario.
An X system's IT team creates and manages X.509 certificates for application authentication.
Security Team issues root certificates and intermediate certificates.
In the situation that the Security team detects that a certificate is compromised, this team could decide to revoke the intermediate certificate to avoid any data leakage. This team does not have access to the MongoDB Atlas portal because they do not manage the databases. As a result of this action, it is expected that all X.509 certificates issued under this authority chain will be unable to connect to MongoDB clusters.
Geoffrey
shared this idea
·
-
39 votesGeoffrey
supported this idea
·
-
8 votesGeoffrey
supported this idea
·
-
14 votesGeoffrey
supported this idea
·
-
3 votesGeoffrey
supported this idea
·
-
7 votesGeoffrey
supported this idea
·
-
4 votesGeoffrey
supported this idea
·
-
4 votes
An error occurred while saving the comment Geoffrey
commented
It can be very usefull if the database user can be automaticaly disable after x unsuccessfully login try.
Geoffrey
supported this idea
·
I vote for this feature again.
This feature is very useful in the context that we need to recover or revalidate the contents of a database at a specific time without having to recover the entire cluster.
Saves time and money.
Hoping that this time will be the right one.