What is the easiest way to start a mongodb copy server? 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 mongod with a --replSet name 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 rs.status() and rs.conf() in the mongo shell).
Create your new EC2 instance and start up a new mongod process as a member of the same replica set (i.e. including the same --replSet name 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 mongo shell and add the new mongod process as a secondary node:

rs.add("mynewec2:27017")

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 mongod host, and restart the new mongod in 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