Replica Sets with Four or More Members

Although the standard replica set configuration has three members you can deploy larger sets. Add additional members to a set to increase redundancy or to add capacity for distributing secondary read operations.

When adding members, ensure that:

  • The set has an odd number of voting members. If you have an even number of voting members, deploy an arbiter so that the set has an odd number.

    The following replica set needs an arbiter to have an odd number of voting members.

    Diagram of a four member replica set plus an arbiter for odd number of votes.
  • A replica set can have up to 12 members, [1] but only 7 voting members. See non-voting members for more information.

    The following 9 member replica set has 7 voting members and 2 non-voting members.

    Diagram of a 9 member replica set with the maximum of 7 voting members.
  • Members that cannot become primary in a failover have priority 0 configuration.

    For instance, some members that have limited resources or networking constraints and should never be able to become primary. Configure members that should not become primary to have priority 0. In following replica set, the secondary member in the third data center has a priority of 0:

    Diagram of a 5 member replica set distributed across three data centers. Replica set includes a priority 0 member.
  • A majority of the set’s members should be in your applications main data center.

[1]While replica sets are the recommended solution for production, a replica set can support only 12 members in total. If your deployment requires more than 12 members, you’ll need to use master-slave replication. Master-slave replication lacks the automatic failover capabilities.