Luke
My feedback
8 results found
-
4 votesLuke
supported this idea
·
-
1 voteLuke
shared this idea
·
-
21 votes
An error occurred while saving the comment Luke
supported this idea
·
-
167 votesLuke
supported this idea
·
-
167 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.
Luke
supported this idea
·
-
11 votes
An error occurred while saving the comment Luke
commented
The way it could work would be by adding a new node to the cluster (non-voting, data bearing, hidden) which stays on the old major version. It could be configured to stick around for 1-48 hours after the major version upgrade still receiving replication of data, during which time it could be used to roll back with no down time.
After the configured downgrade period elapsed, Atlas would kill the node running on the old major version.
This would be a really great feature and save us a ton of heartache during major upgrades!
Luke
supported this idea
·
-
47 votes
An error occurred while saving the comment Luke
commented
Using our own domain names is really important for us.
We use AWS Private Endpoint URLs in our docker Java application and Python lambdas.
If the connection string could be a CNAME / Alias DNS record of our own which we could switch to point at different databases we could handle the rollback safely without any redeployment. After changing the DNS, we could allow the TTL to expire + pause the original cluster, causing all the connections to be re-established with the database of our choice without any configuration changes or app/lambda redeployments.
e.g. Major Version Upgrade (rollback on failure)
When upgrading major versions, there is no automatic rollback to the prior version supported. So our solution is to have a backup cluster spun up alongside the production cluster with a recent snapshot, running the old major version. As we upgrade the production cluster to the new major one; should anything go wrong we can roll back to the backup cluster.
This process would be significantly hampered by the need to change the connection strings and redeploy all of the lambdas and applications, and would slow down + threaten the integrity (should we miss something) of the rollback procedure.
It would also be cool if we could have a major version downgrade option in Atlas.
The way it could work would be by adding a new node to the cluster (non-voting, data bearing, hidden) which stays on the old major version. It could be configured to stick around for 1-48 hours after the major version upgrade still receiving replication of data during which time it could be used to roll back with no down time.Luke
supported this idea
·
-
160 votesLuke
supported this idea
·
For inspiration, see the excellent open source Robomongo (not the terrible commericialisation Robo 3t). That is still the only IDE which really nailed the UX for MonogDB.