concept replica set in category mongoDB

This is an excerpt from Manning's book MongoDB in Action, Second Edition: Covers MongoDB version 3.0. Login to get full access to this book.

Figure 1.3. Automated failover with a replica set

MongoDB provides database replication via a topology known as a replica set. Replica sets distribute data across two or more machines for redundancy and automate failover in the event of server and network outages. Additionally, replication is used to scale database reads. If you have a read-intensive application, as is commonly the case on the web, it’s possible to spread database reads across machines in the replica set cluster.

Replica sets consist of many MongoDB servers, usually with each server on a separate physical machine; we’ll call these nodes. At any given time, one node serves as the replica set primary node and one or more nodes serve as secondaries. Like the master-slave replication that you may be familiar with from other databases, a replica set’s primary node can accept both reads and writes, but the secondary nodes are read-only. What makes replica sets unique is their support for automated failover: if the primary node fails, the cluster will pick a secondary node and automatically promote it to primary. When the former primary comes back online, it’ll do so as a secondary. An illustration of this process is provided in figure 1.3.

Figure 1.3. Automated failover with a replica set

We’ll begin this chapter by introducing replication and discussing its main use cases. Then we’ll cover MongoDB’s replication through a detailed study of replica sets. Finally, we’ll describe how to connect to replicated MongoDB clusters using the drivers, how to use write concerns, and how to load-balance reads across replicas.

Replica sets are excellent for scaling reads that don’t require immediate consistency, but they won’t help in every situation. If you need to scale and any of the preceding conditions apply, then you’ll need a different strategy, involving sharding, augmented hardware, or some combination of the two.

priority —A decimal number from 0 to 1000 that helps to determine the relative eligibility that this node will be elected primary. For both replica set initiation and failover, the set will attempt to elect as primary the node with the highest priority, as long as it’s up to date. This might be useful if you have a replica set where some nodes are more powerful than the others; it makes sense to prefer the biggest machine as the primary. There are also cases where you might want a node never to be primary (say, a disaster recovery node residing in a secondary data center). In those cases, set the priority to 0. Nodes with a priority of 0 will be marked as passive in the results to the isMaster() command and will never be elected primary. Here’s an example of setting the member’s priority:

{
  "_id" : 0,
  "host" : "iron:40000",
  "priority" : 500
}

copy