Our mongodb server is running on AWS EC2 - it is using up a lot of the cpus of this server - which is also our Apache server - How Can I easily migrate the mongodb to another EC2 dedicated server?
If you want to migrate with minimal downtime, a straightforward approach would be to use MongoDB replication:
Convert your current standalone node to a replica set by restarting your current
--replSetname and then running
rs.initiate(). NOTE: The
rs.initiate()step is a once off command that only needs to be run on a primary when the replica set is first created.
If all went well, you should now have a single node replica set with your former standalone node as the primary (check
Create your new EC2 instance and start up a new
mongodprocess as a member of the same replica set (i.e. including the same
--replSetname in the configuration). To avoid any unexpected issues, the new node should be running the same version of MongoDB as your original standalone server.
Connect to your primary via the
mongoshell and add the new
mongodprocess as a secondary node:
You should now have a two node replica set with a primary node and secondary node (which may be in a "startup" or "recovering" phase while data is syncing).
NOTE: For a production MongoDB replica set configuration you would normally want to have a third node to maintain a quorum. This can either be a secondary or an arbiter, which is a voting-only node that does not hold any data and only participates in elections. For the purposes of your migration a third node is optional, but recommended in the event there are any problems with the secondary while the data is being synced. With a two node replica set, both nodes must be online in order to maintain a primary. A three node replica set allows for fault tolerance of 1 node failure.
Assuming there were no firewall or communication errors, the node you added as a secondary should begin to sync data over the network from your original (primary node). Note: there are alternative ways to sync a replica set member (for example starting from a file copy backup).
You can follow the sync progress using
db.printSlaveReplicationInfo()on the primary.
Once your secondary node has caught up with the current primary (or is within 10s of the oplog time of the primary) you can use
rs.stepDown(60)to force the current primary to stepdown. This should cause your secondary (newly provisioned host) to become the primary.
At this point the migration is complete: you can now shutdown your original
mongodhost, and restart the new
mongodin standalone mode.
To minimise the impact to application writes during this period, you can either:
change your application to use a replica set connection so writes will automatically change to the current primary
coordinate changing your application connection string with the stepdown of the (former) standalone primary