AdminAndrew Davidson
(VP, Cloud Products, MongoDB)
My feedback
180 results found
-
1 vote
An error occurred while saving the comment -
15 votes
An error occurred while saving the comment Hi Chad,
Note that the managed add index capability is specifically in order to do a rolling index build which essentially minimizes the impact of the build on operational performance (similar to a background index build but even more offline by pulling nodes temporarily out of client visibility entirely while building).
Dropping indexes does not have a comparable operational impact, so you can do those with direct MongoDB wire protocol access to the cluster itself (you can do the same with building indexes where a traditional foreground or background index build suffices).
Can you shed any light on what managing this through the Atlas control plane API would do for you that managing it through the cluster directly doesn't?
-Andrew -
2 votes
An error occurred while saving the comment Thanks that's helpful. Note that you can specify multiple tags in a read preference tag set, e.g. both "ELECTABLE" and "READ_ONLY" but it's true that the driver will use the first one in the list that it can reach meaning that unless you were to have some clients use one order and others use the reverse, you'd not distribute the workload across all available secondaries. We'll need to track these use cases and explore options over time.
An error occurred while saving the comment Hi Charles,
Can you share a little more detail on what you're aiming to achieve: For example why not use nearest or secondary read preferences?
Cheers
-Andrew -
1 vote
An error occurred while saving the comment Hi Jason,
You may have seen that AWS's model has built-in protection for folks that abuse it https://aws.amazon.com/premiumsupport/faqs/ "We reserve the right to refuse to provide AWS Support to any customer that frequently registers for and terminates the service."
In the interests of transparency, our goal over here at MongoDB Cloud is the same: We want to ensure that you're getting the help you need when you need it, while also protecting ourselves from abuse. Support subscriptions are a little bit like insurance, with the business model around them predicated on the assumption that they're enabled most of the time, with help provided a subset of time therein.
Put another way, running a world class support team with incredible technical talent that can provide end to end assistance to customers is something that is a major business investment, and something that needs to be delivered as part of a broader business strategy.
I will share with you that contrary to what the cancellation modal implies, we do not currently bill you for the time between canceling and re-activating Atlas Developer in the future (in other words, our billing engine simply doesn't actually follow through on that). We will monitor and look for signs of abuse, however, and I do anticipate implementing logic to back-bill for up to three months in future for this case.
By the way, we offer the first month free, *and* provide as much assistance as we can through our in-app chat to everyone included pro bono in the core Atlas service.
Cheers
-Andrew -
1 vote
An error occurred while saving the comment Hi Mike,
Thanks for flagging: this has been reported to us a number of times since the launch of MongoDB Atlas.
I've personally reached out to folks at Zapier each time. However, I suspect they would prefer to hear it directly from you, a Zapier user.
Would you mind reaching out to them directly? I'll do the same now.
Thank you
-Andrew -
5 votes
An error occurred while saving the comment Hi Pavel, thanks for filing. Note that Azure also has a Switzerland region today (on top of GCP). AWS does not, however. When or if AWS does introduce a Switzerland region in the future, assuming it's a standard region with the necessary building blocks, we will be excited to launch Atlas there!
Cheers
-Andrew -
2 votes
An error occurred while saving the comment After testing, our understanding is that the atlasAdmin user does have the rights to use the movePrimary connect today.
We have identified an incorrect part of our documentation that will be fixed shortly on this topic.
-
9 votes
An error occurred while saving the comment 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.
-
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
-
9 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.
-
4 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.
-
4 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.
-
7 votes
An error occurred while saving the comment Why is this important to you? What's driving this request?
-
13 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.
-
12 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.
-
4 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
-
4 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
Hi Theodore,
We hear you loud and clear on this one and it's something we'd like to eventually optimize. However our customers that have run into this challenge have often found that moving to programmatic management of their alert settings via the MongoDB Cloud API offers an alternative way of achieving this goal.
I realize this is primarily helpful if you're setting on Projects often and doing so programmatically and that this may not feel worth the effort if you're doing this only occasionally so this is not an optimal path for everyone.
-Andrew