Five New Replica Set Features in 1.7.x

Here’s a rundown of some of the most useful features added recently. These are all available in 1.7.4 and will, of course, be in 1.8.

1. Initial sync from a secondary

   You can now set an initialSyncsource for each member, which controls where the new guy will sync from. For example, if you wanted to add a new node and force it to sync from a secondary, you could do:

   > rs.add({"_id" : num, "host" : hostname, "initialSync" : {"state" : 2}}) 
   

   You can choose a sync source by its state (primary or secondary), _id, hostname, or up-to-date-ness. For the last, you can specify a date or timestamp and the new member will choose a source that is at least that up-to-date.

   By default, a new member will attempt to sync from a random secondary and, if it can’t find one, sync from the primary. If it chooses a secondary, it will only use the secondary for its initial sync. Once it’s ready to sync new data, it will switch over and use the primary for “normal” syncing.

2. Slave delay

   This option makes the slave postpone replaying operations from the master. The delay can be specified in seconds in a member’s configuration:

   > rs.add({"_id" : num, "host" : hostname, "slaveDelay" : 3600})
   

3. Hidden

   Hidden servers won’t appear in isMaster() results. This also means that they will notbe 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})
   

4. Freeze a member

   Replica set members abhor a vacuum and will immediately try to elect themselves if the primary disappears. This can make maintenance or a planned failover difficult. Freezing a member forces it to remain a secondary for a given number of seconds (defaults to 60). This can be useful if you want to do some maintenance on the primary and don’t want an usurpers jumping in or you want to force a certain member to become the new primary. To freeze a member, run:

   > rs.freeze(3600)
   

   To unfreeze at any time:

   > rs.freeze(0)
   

5. Fast sync

   If you have a backup that’s reasonably up-to-date, you can bring up a new member quickly with a fast sync. Start the new member --dbpath set to your backup and --fastsync (as well as --replSet, --oplogSize, and whatever else you usually specify). Instead of copying all of the data from the master, it will just replay the latest operations.

   You can check if a backup is recent enough to fast sync by connecting to the primary and running:

   > use local
   > new Date(db.oplog.rs.find().sort({$natural:1}).limit(1).next()["ts"]["t"])
   

   If your backup is from after the date displayed, you can catch up to the master using fast sync. If not, you’ll need to resync from scratch.

There are lots more replica set features coming soon: authentication, syncing from secondaries beyond the initial sync, data center awareness, and more. If there are any features you’d particularly like to see, be sure to vote on the cases you care about.