AdminAndrew Davidson
(VP, Cloud Products, MongoDB)
My feedback
173 results found
-
10 votes
An error occurred while saving the comment -
3 votes
An error occurred while saving the comment This makes sense eventually but is not a high priority over the near to medium term because the clusterMonitoring role can be used. Thanks for filing
-
15 votes
An error occurred while saving the comment Hi Eric, We'd like to make a change in the future to do this automatically for you because we completely agree that it's the primary-ness that matters not the node-ness. It's a fairly large scale refactor to get there so this will not be possible over the near term unfortunately, but we want to do it.
-
5 votes
An error occurred while saving the comment Thank you for flagging this. In the interests of transparency, we are working on a large-scale effort to revamp how MongoDB Cloud role based access control works, in order to enable much more fine grained privileged actions to be defined on specific resources. This is a top priority but a significant undertake so the user-facing aspect of this change remains multiple quarters out. Please bear with us while we do this work to unlock this and many other use cases in future.
-
5 votes
An error occurred while saving the comment I think we can all agree that this would be very useful: it's not easy to achieve unfortunately so will not realistically be possible over the near to medium term.
-
8 votes
An error occurred while saving the comment Why is this important to you? What's driving this request?
-
16 votes
An error occurred while saving the comment Please note that the expectation is that customers requiring longer retention will archive logs to their own infrastructure, with object storage or an SIEM. Log pulling can be programmatically instrumented using the MongoDB Atlas API. Partners like Sumo Logic and jSonar have existing pull-based integrations.
-
1 vote
An error occurred while saving the comment For completeness, please note that that customers keen to leverage MongoDB Atlas for ePHI data can sign a BAA with MongoDB: MongoDB Cloud stands ready for HIPAA workloads.
MongoDB has also undergone third party compliance certificates under the SOC-2 Type 2, ISO-27001, and PCI-DSS standards.
More information including our Security whitepaper can be found here: https://www.mongodb.com/cloud/trust
-
1 vote
An error occurred while saving the comment What's the use case / business value of this request? Please provide more information when filing something like this if you are hoping for it to be helpful for prioritization purposes.
-
13 votes
An error occurred while saving the comment Can you elaborate more on the use case and why this is important? What are you trying to do that requires this, or is it more of a hypothetical?
-
1 vote
An error occurred while saving the comment A clarification: Atlas clusters can be paused for up to 30 days.
-
6 votes
An error occurred while saving the comment Hi Itay, I'm sorry to hear that this happened. Have you looked at using Billing Alerts (they can be configure at the Project and Org level): https://docs.atlas.mongodb.com/reference/alert-conditions/#billing-alerts
-
6 votes
An error occurred while saving the comment Hi Baris,
This is a great idea, similar to what we have done for IP whitelist entries. You might look at whether those could be used as a proxy for this over the near term, assuming you're whitelisting each peered VPC's private CIDR range separately. I'd love to get you a better solution eventually.
-Andrew
-
2 votes
An error occurred while saving the comment Great idea, Thomas. We actually support cluster-level key-value pair tagging today, but via API only. We need to eventually bring this concept to the Project-level, and make both visible/usable in the UI context as well. There are many use cases for this, ranging from what you've described, to being able to help with automation and billing management.
-Andrew
-
3 votes
An error occurred while saving the comment Hi Samith,
Great concept but it's not straight forward to be able to deduce the amount of a particular cluster's cost that each constituent database/namespace is responsible for. For example, is storage usage the key driver, or workload intensity, or some combination therefore?
For what it's worth, we do have a billing API as well as monitoring metrics API so you could use together to do some of what you're aiming to do but you'll need to come up with the logic yourself.
Have you looked into using the MongoDB Atlas M2 and M5 cluster tiers to offer low-priced starter tier clusters with multi-tenant economics? I can see that this might not be workable depending on your goal cost per tenant, but wanted to point it out as an option.
Cheers
-Andrew -
7 votes
An error occurred while saving the comment Hi Kyle, There are a number of serious downsides to using arbiters: for example it's not possible to use majority writes during maintenance if only one data-bearing node remains online temporarily.
Out of curiosity, if it were possible to deploy a third replica on GCP or Azure, would that suffice? I ask because we've had a long-term roadmap objective to enable true multi-cloud clusters on Atlas and we see situations like this, where you're looking increase in-country availability as a great use case for this.
Cheers
-Andrew -
1 vote
An error occurred while saving the comment Hi Daniel,
I'm sorry you're running into this, but it's a nuanced one: peering with public ranges means giving up internet access which could potentially alter the manageability of the Atlas-side cluster and this is not something we can consider.
If you're using public ranges in a private VPC, I strongly suggest that you either move to a private range and if that's not palatable, consider using either selective public IP Whitelisting or Atlas Private Endpoints (powered by AWS PrivateLink).
Cheers
-Andrew -
39 votes
An error occurred while saving the comment Hi Dan, We've hoped that folks would find the Atlas shared tier (M0 free tier, M2, and M5) offerings would address the lower-cost offering category. Have you explored these offerings: is there anything we can do to improve them to better service your needs?
-
19 votes
An error occurred while saving the comment It's important to emphasize that if ever folks are finding that an application needs to be restarted after MongoDB Atlas cluster-level maintenance, then there is a critical issue that needs to be addressed in the application, potentially in the driver that needs to be addressed.
If this happens to folks, please work with MongoDB support to get to the bottom of these issues which are completely antithetical to the continuous availability which MongoDB aims to deliver.
-
1 vote
An error occurred while saving the comment Hi Scott, I do want to make sure you've seen the API endpoint for this https://docs.atlas.mongodb.com/reference/api/organization-get-all-invoices/
Note that you can *restore* directly from a Cloud Manager backup to a MongoDB Atlas cluster *today*.
However, a backup restore is different from a live migrate since it will be from a point in time.
Atlas separately offers a Live Migration service which connects to your existing MongoDB environment, performs an initial sync-style data load and then applies oplog to keep the Atlas side destination cluster in sync and up to date in terms of op-time. Once the Atlas-side cluster is caught up, you can quiesce writes to your source cluster and bounce your application servers over to the Atlas cluster.