Skip to content

Luke

My feedback

7 results found

  1. 1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Luke shared this idea  · 
  2. 16 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Luke commented  · 

    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.

    Luke supported this idea  · 
  3. 160 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Atlas » Other  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Luke supported this idea  · 
  4. 132 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    27 comments  ·  Atlas » Backup  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Luke supported this idea  · 
  5. 10 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Atlas » Other  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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  · 
  6. 42 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    14 comments  ·  Atlas » Other  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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  · 
  7. 156 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Luke supported this idea  · 

Feedback and Knowledge Base