11

I've got a single dedicated server with a MongoDB database of around 10GB. I need to do daily backups, but I can't have downtime with the database. Is it possible to use a replica set on a single disk (with 2 instances of mongod running on different ports), and simply take the secondary one offline and backup the data files to an offsite storage such as S3 (journaling is turned on)? Or would using master/slave be better than a replica set?

Is this viable, and if so, what potential problems could I have? If not, how do I conceptualize this to work?

James Simpson
  • 1,601
  • 2
  • 14
  • 30

3 Answers3

6

ReplicaSet will work in this scenario. However, I cannot tell if having two MongoDB instances at the same server is a good idea -- this depends on the server hardware/software and load.

To make sure your backup MongoDB node does not become master, set its priority parameter to 0, e.g.

rs.add({_id: 1, host: "localhost:<port>", priority: 0})

NOTE: if you cannot have downtime, you SHOULD have at least 2 primary MongoDB nodes in ReplicaSet, see article

Alexander Azarov
  • 3,510
  • 20
  • 19
2

One strategy to consider is using the "hidden" option on the backup node on your replicaset. From the MongoDB blog:

Hidden servers won’t appear in isMaster() results. This also means that they will not be used if a driver automatically distributes reads to slaves. A hidden server must have a priority of 0 (you can’t have a hidden primary). To add a hidden member, run:

rs.add({"_id" : num, "host" : hostname, "priority" : 0, "hidden" : true})

Travis Dunn
  • 31
  • 1
1

Replica sets are preferred in general but also in this case simply because of their auto-recovery and auto-resync functionality. The backup method you are describing sounds perfectly reasonable and has been used before with other databases as well.

The only potential problem I see is that under certain circumstances your secondary may be promoted to your primary and you'll either a) need to take your backup from the new secondary, or b) make your backup script smart enough to tell that instance of MongoDB to step down.

The good news is that it should be fairly trivial to

  1. Query your backup source to find out which instance is primary and which is secondary (db.isMaster())
  2. Convince backup instance to step down using the rs.freeze() and rs.stepDown() commands or reconnect to secondary
Charles Hooper
  • 1,500
  • 9
  • 8
  • Is it not an option to set the priority to 0 like Alexander suggests so that the secondary never becomes the primary? – James Simpson Jun 28 '11 at 17:12
  • You'd have to do some testing, but I 'm not sure if the secondary will just standby if for some reason the primary process goes down. I've always wanted my secondaries to take over ;) – Charles Hooper Jun 28 '11 at 18:19
  • 1
    >> your secondary may be promoted to your primary -- As mentioned, setting the secondary to priority 0 will prevent it from ever switching to master. – Jonesome Reinstate Monica Jul 20 '11 at 03:58
  • You could connect to any one of the peers from your list of peer nodes (it could be any primary, secondary, arbiter, or hidden node), ask that peer who the secondaries are (`rs.status()` and loop through `result["members"]`), and connect to one of the secondaries to perform the backup. – yfeldblum Nov 26 '11 at 15:04