I currently have a M0 cluster containing ~350Mb of data.
As my data grows I plan to upgrade my cluster tier to a higher shared tier / decidated tier (M0 → M2/M5/M10) however at this point in time I do not require the storage an M10 cluster provides.
I am exploring my options to plan for my upgrade and would appreciate your advice.
Questions:
The Modify a Cluster document advises to halt writes to the cluster and that downtime is required for any shared tier cluster upgrades - are there any other preperation steps I need to consider?
Can you provide any indication of the expected downtime (seconds/minutes/hours) required for a shared tier cluster upgrade and is there any way for me to mimimise this downtime?
Is there any difference in the downtime required for a shared tier cluster upgrade either between shared tiers (e.g. M0 → M2 | M0 → M5 | M2 → M5) or from shared tier to dedicated tier (e.g. M0 → M10 | M2 → M10 | M5 → M10) or due to amount of data in the cluster?
The documentation advises that if upgrading between shared tiers (e.g. M0 → M2 → M5 → M10) that downtime would be required for each shared tier cluster upgrade, my understanding is that any dedicated tier cluster upgrades (e.g. M10 → M20+) do not require downtime - is my understanding correct?
Additional considerations:
When I upgrade to an M10 cluster billing is $0.08/hr, is this base price adjusted for ‘in use’ i.e. only billed for time when the cluster is responding to queries or is this ‘on’ i.e. if billed per hour the cluster is available?
My calculations put a base M10 cluster at ~730hr/month * $0.08/hr = ~$60/month, is there any way to reduce this apart from shutting down/destroying the cluster or is this the minimum base price for a always available dedicated tier cluster?
What is the recomended way to upgrade a shared cluster (M0/2/5) if the cluster has a Mongo Realm app attached to it - how would I stop the Realm app writing to the Atlas database during the upgrade (or is this not a consideration because the Realm app would also be unavailable during the cluster tier move and hence not writing to the cluster)?
Re (1) other than halting writes until the cluster’s data has moved to a dedicated cluster, nothing else comes to mind: the M2 and M5 clusters are architecturally identical to the M0, just larger. The M10+ clusters on the other hand are dedicated: this opens up features and capabilities that weren’t there on the shared tier, like private networking
Re (2) a shared tier upgrade should take on the order of ~10 minutes: most of the time goes into 1. DNS propagation for the connection sting to route to a new backend, and 2. of course movement of the actual data.
Re (3) Nope the downtime should be commensurate: though it will correlate with the data size that needs to be moved, so a full 5GB M5 would take a bit longer to move than a 0.5GB M0.
Re (4) That’s correct, once on a dedicated cluster tier, the upgrades are done in a rolling manner within the same logical database cluster, which preserves continuous availability save for momentary replica-set level elections: unfortunately this paradigm isn’t possible when shifting between shared tier backends or between the shares tier architecture and dedicated.
Re (5) The billing is based on the cluster simply being on, because it’s dedicated and continuously deployed for your use: you can, however, optionally pause your cluster when you’re not actively using it (this can be useful for non-prod environments outside of work hours). Doing so lowers the cost to storage only during the paused period, and you can resume a cluster that’s paused at any time.
Re (6) Correct an M10 cluster costs ballpark $60 per month at baseline – the best way to reduce would be to pause as mentioned above. We are actively working on something we’ll be excited to announce in future that I think you’ll find very compelling for non-continuous workloads (I hope you’re attending MongoDB .LIVE in 2 weeks!)
Re (7) Great question: ideally you would quiesce activity within your Realm app during the upgade: is that an option for you?
Thank you for all of your answers that helps a lot.
Re (6) Thank you for the clarification … and for piquing my interest!
Re (7) Perfect, as expected ‘good’ practice would be do the upgrade in a low traffic maintenance window when the Realm app shutdown during the shared tier cluster upgrade would impact few / no users as there is no way on the server to have Realm present a maintenance notification. Best practice would be to use a dedicated cluster to avoid the downtime altogether
