CODEWITHSUNDEEP
mongodbdatabase-migration
Afshin Mehrabani
Afshin Mehrabani

Reputation: 34929

Migrating MongoDB instances with no down-time

We are using MongoDB in production environment and now, due to some issues of current servers, I'm going to change the server and start a new MongoDB instance.

We have a replica set and a single mongod instance (two different MongoDB networks for different purposes). Now, first I should migrate the single mongod instance and then the whole replica set to the new server.

What I want to know is, how can I migrate both instances with no down-time? I don't want to shutdown the server or stop write operations.

Thanks in advance.

Upvotes: 10

Views: 6575

Answers (4)

Nitin G
Nitin G

Reputation: 46

You cannot have no downtime (a new mongod will run on new IP so you need to at least connect to it). But you can minimize downtime by making geographically distributed replica set.

Please Read http://docs.mongodb.org/manual/tutorial/deploy-geographically-distributed-replica-set/

Use the given process but please note:

  1. Do not set priority 0 of instances at New Location so that they become primary when old ones at Old Location step down.
  2. You still need to restart mongod in replica set mode at Old Location.
  3. You need 3 instances including an arbiter at New Location, if you want it to be replica set.
  4. When complete data is in sync with instances at New Location, step down instances at Old Location (one by one). Now everything will go to New Location but the problem is that it is directed through a distant mongod.
  5. So stop mongod at Old Location and start a new one at new Location. Connect your applications to New Location Mongod.

Note: I have not done the same so far. I had planned it once but then I got the problem and it was not of hosting provider. Practically you may get some issues.

Upvotes: 2

Paizo
Paizo

Reputation: 4194

John answer is right, btw in your case you have no way to avoid downtime, you can just try to make it shorter as possible.

  1. You can prepare the new replica set and save its configuration.
  2. Same for the single mongod instance, prepare a js file with specific configuration (ie: stuff going on the admin database).
  3. disable client connections on production servers.
  4. copy the datafiles from the old servers to the new ones (http://docs.mongodb.org/manual/core/backups/#backup-with-file-copies)
  5. apply your previous saved replica set config and configuration.
  6. done

you can use diffent ways as add an hidden secondary member on the replica set if you have a lot of data, so you can wait it's is up-to-date before stopping the production server. Basically for the replica set you have many ways to handle a migration, with the single instance instead you don't have such features.

Upvotes: 1

Diwakar upadhyay
Diwakar upadhyay

Reputation: 434

Replica Set is the feature provided by the Mongodb database to achieve high availability and automatic failover.

It is kinda traditional master-slave configuration but have capability of automatic failover.

It is basically group/cluster of the mongod instances which communicates, replicates to each other to provide high availability and to do automatic failover

Basically, in replica sets there are minimum 2 and maximum of 12 mongod instances can exist

In replica set following types of server exist. out of all, one server is always primary.

http://blog.ajduke.in/2013/05/31/setup-mongodb-replica-set-in-4-steps/

Upvotes: 1

John Petrone
John Petrone

Reputation: 27497

So first of all you should never run mongodb as a single instance for production. At a minimum you should have 1 primary, 1 secondary and 1 arbiter.

Second, even with a replica set you will always have a bit of write downtime when you switch primaries, as writes are not possible during the election process. From the docs:

IMPORTANT Elections are essential for independent operation of a replica set; however, elections take time to complete. While an election is in process, the replica set has no primary and cannot accept writes. MongoDB avoids elections unless necessary.

Elections are going to occur when for example you bring down the primary to move it to a new server or virtual instance, or upgrade the database version (like going from 2.4 to 2.6).

You can keep downtime to a minimum with an existing replica set by setting the appropriate options to allow queries to run against secondaries. Again from the docs:

Maintaining availability during a failover. Use primaryPreferred if you want an application to read from the primary under normal circumstances, but to allow stale reads from secondaries in an emergency. This provides a “read-only mode” for your application during a failover.

This takes care of reads at least. Writes are best dealt with by having your application retry failed writes, or queue them up.

Regarding your standalone the documented procedures for converting to a replica set are well tested and can be completed very quickly with minimal downtime:

http://docs.mongodb.org/manual/tutorial/convert-standalone-to-replica-set/

Upvotes: 10

Related Questions