Our team is currently exploring the process of migrating MongoDB to an ARM-based virtual machine (AWS Graviton) in order to reduce our cloud spending costs. However, since this is new to everyone on our team, we’re unsure about the migration process for ARM-based workloads. Therefore, we would greatly appreciate any assistance you can provide in guiding us through the necessary steps for migration.
If you have any documentation that outlines the migration process for ARM-based workloads, please share it with us. We are eager to learn as much as we can about this process and make this transition as smooth as possible.
Thank you in advance for your support and any advice you can offer.
Hello Abinas Roy, Thank you for your response. Unfortunately, I couldn’t raise support with MongoDB.
Is the issue being tracked somewhere else? If yes, could you please share the link with me?
The approach I’d take with this is the following. This is an online minimal/no downtime approach.
I have not tested this with members of differing CPU architectures, so testing in a non-prod environment would be recommended.
Start the three new member(assuming a 3 member replicaset).
Update application connection strings to include new members. (existing connections will receive topology updates, but if an app is restarted it will need correct seeds).
Add the new member to the replicaset.
Switch Primary to a new member. Could be a series of rs.stepDown(300) until a desired primary is reached, or set the priority of new members higher than existing members.
Optional: Reconfigure old members to votes:0, priority:0 this can allow for a faster rollback if needed.
Remove old members from replica set.
Update application connection strings to remove old members.
If the database is small enough and/or a tolerance for downtime exists then a mongodump/mongorestore might suit you well enough.