Replica Set Deployment Architectures

The architecture of a replica set affects theset’s capacity and capability. This document provides strategies forreplica set deployments and describes common architectures.

The standard replica set deployment for production system is athree-member replica set. These sets provide redundancy and faulttolerance. Avoid complexity when possible, but let your applicationrequirements dictate the architecture.

Strategies

Determine the Number of Members

Add members in a replica set according to these strategies.

Maximum Number of Voting Members

A replica set can have up to 50 members, but only 7 voting members. If the replica set already has 7 votingmembers, additional members must be non-voting members.

Deploy an Odd Number of Members

Ensure that the replica set has an odd number of voting members. If youhave an even number of voting members, deploy an arbiter so that the set has an odd number of votingmembers.

An arbiter does not store a copy of the data andrequires fewer resources. As a result, you may run an arbiter on anapplication server or other shared process. With no copy of the data,it may be possible to place an arbiter into environments that you wouldnot place other members of the replica set. Consult your securitypolicies.

For the following MongoDB versions, pv1 increases the likelihoodof w:1 rollbacks compared to pv0(no longer supported in MongoDB 4.0+) for replica sets with arbiters:

  • MongoDB 3.4.1
  • MongoDB 3.4.0
  • MongoDB 3.2.11 or earlier

See Replica Set Protocol Version.

Warning

In general, avoid deploying more than one arbiter per replica set.

Consider Fault Tolerance

Fault tolerance for a replica set is the number of members that canbecome unavailable and still leave enough members in the set to elect aprimary. In other words, it is the difference between the number ofmembers in the set and the majority of voting members needed toelect a primary. Without a primary, a replica set cannot accept writeoperations. Fault tolerance is an effect of replica set size, but therelationship is not direct. See the following table:

Number of MembersMajority Required to Elect a New PrimaryFault Tolerance
321
431
532
642

Adding a member to the replica set does not always increase thefault tolerance. However, in these cases, additional members canprovide support for dedicated functions, such as backups or reporting.

Starting in version 4.2.1, rs.status() returnsmajorityVoteCount for the replica set.

Use Hidden and Delayed Members for Dedicated Functions

Add hidden or delayed members to support dedicated functions,such as backup or reporting.

Load Balance on Read-Heavy Deployments

In a deployment with very high read traffic, you can improve readthroughput by distributing reads to secondary members. As yourdeployment grows, add or move members to alternate data centers toimprove redundancy and availability.

Note

Distributing replica set members across two data centers providesbenefit over a single data center. In a two data centerdistribution,

  • If one of the data centers goes down, the data is still availablefor reads unlike a single data center distribution.
  • If the data center with a minority of the members goes down, thereplica set can still serve write operations as well as readoperations.
  • However, if the data center with the majority of the members goesdown, the replica set becomes read-only.

If possible, distribute members across at least three data centers.For config server replica sets (CSRS), the best practice is todistribute across three (or more depending on the number of members)centers. If the cost of the third data center is prohibitive, onedistribution possibility is to evenly distribute the data bearingmembers across the two data centers and store the remaining member(either a data bearing member or an arbiter to ensure odd numberof members) in the cloud if your company policy allows.

Always ensure that the main facility is able to elect a primary.

Add Capacity Ahead of Demand

The existing members of a replica set must have spare capacity tosupport adding a new member. Always add new members before thecurrent demand saturates the capacity of the set.

Distribute Members Geographically

To protect your data in case of a data center failure, keep at leastone member in an alternate data center. If possible, use an odd numberof data centers, and choose a distribution of members that maximizesthe likelihood that even with a loss of a data center, the remainingreplica set members can form a majority or at minimum, provide a copyof your data.

Note

Distributing replica set members across two data centers providesbenefit over a single data center. In a two data centerdistribution,

  • If one of the data centers goes down, the data is still availablefor reads unlike a single data center distribution.
  • If the data center with a minority of the members goes down, thereplica set can still serve write operations as well as readoperations.
  • However, if the data center with the majority of the members goesdown, the replica set becomes read-only.

If possible, distribute members across at least three data centers.For config server replica sets (CSRS), the best practice is todistribute across three (or more depending on the number of members)centers. If the cost of the third data center is prohibitive, onedistribution possibility is to evenly distribute the data bearingmembers across the two data centers and store the remaining member(either a data bearing member or an arbiter to ensure odd numberof members) in the cloud if your company policy allows.

To ensure that the members in your main data center be elected primarybefore the members in the alternate data center, set themembers[n].priority of the members in the alternate datacenter to be lower than that of the members in the primary data center.

For more information, seeReplica Sets Distributed Across Two or More Data Centers

Target Operations with Tag Sets

Use replica set tag sets totarget read operations to specific members or to customize writeconcern to request acknowledgement from specific members.

See also

Data Center Awareness andWorkload Isolation in MongoDB Deployments.

Use Journaling to Protect Against Power Failures

MongoDB enables journaling by default.Journaling protects against data loss in the event of serviceinterruptions, such as power failures and unexpected reboots.

Hostnames

Tip

When possible, use a logical DNS hostname instead of an ip address,particularly when configuring replica set members or sharded clustermembers. The use of logical DNS hostnames avoids configurationchanges due to ip address changes.

Replica Set Naming

If your application connects to more than one replica set, each setshould have a distinct name. Some drivers group replica setconnections by replica set name.

Deployment Patterns

The following documents describe common replica set deploymentpatterns. Other patterns are possible and effective depending onthe application’s requirements. If needed, combine features of eacharchitecture in your own deployment: