Why Replica Sets

Replica sets provide five distinct benefits over the use of a single node.

A system requiring one or more of the following features should consider using replica sets.

Data Redundancy

  • Replica sets provide an automated method for storing multiple copies of your data.
  • Supported drivers allow for the control of "write concerns". This allows for writes to be confirmed by multiple nodes before returning a success message to the client.

Automated Failover

  • Replica sets will coordinate to have a single primary in a given set.
  • Supported drivers will recognize the change of a primary within a replica set.
    • In most cases, this means that the failure of a primary can be handled by the client without any configuration changes.
  • A correctly configured replica set basically provides a “hot backup”. Recovering from backups is typically very time consuming and can result in data loss. Having an active replica set is generally much faster than working with backups.

Read Scaling

  • The primary means to scale in MongoDB is sharding. Replicas are foremost for data safety, high availability, and redundancy.  That said, it is possible to perform queries  on secondaries.
  • By default, the primary node of a replica set is accessed for all reads and writes.
  • Most drivers provide a slaveOkay method for identifying that a specific operation can be run on a secondary node. When using slaveOkay, a system can share the read load amongst several nodes.
  • Unless there is an explicit need, we recommend simply querying the primaries.  This keeps things simples and assures immediate consistency for the data read.

Maintenance

  • When performing tasks such as upgrades, backups and compaction, it is typically required to remove a node from service.
  • Replica sets allow for these maintenance tasks to be performed while operating a production system. As long as the production system can withstand the removal of a single node, then it’s possible to perform a “rolling” upgrade on such things.

Disaster Recovery

  • Replica sets allows for a “delayed secondary” node.
  • This node can provide a window for recovering from disastrous events such as:
    • bad deployments
    • dropped tables and collections

Next : Setup Basics

Follow @mongodb

MongoDB Pittsburgh - May 15
MongoNYC - May 23
MongoDB Paris - Jun 14
MongoDB UK - Jun 20
MongoDC - June 26


Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

PLEASE POST QUESTIONS IN THE USER GROUPS FORUM. Post non-question comments and helpful hints here.

blog comments powered by Disqus