This version of the documentation is archived and no longer supported.

Configure Non-Voting Replica Set Member

On this page

Non-voting members allow you to add additional members for read distribution beyond the maximum seven voting members.


    Changed in version 3.2:
  • Non-voting members must have priority of 0.

  • Members with priority greater than 0 cannot have 0 votes.

To configure a member as non-voting, set both its votes and priority values to 0.


The following example configures the fourth, fifth, and sixth replica set members to be non-voting members.

  1. In a mongo shell connected to a primary, run the rs.conf() method and assign the result to a variable:

    cfg = rs.conf();

    The returned document contains a members field which contains a zero-indexed array of member configuration documents, one document for each member of the replica set.

  2. To configure the fourth, fifth, and sixth replica set members to be non-voting, use the following command sequence to set both their members[n].votes and members[n].priority values to 0.

    cfg.members[3].votes = 0;
    cfg.members[3].priority = 0;
    cfg.members[4].votes = 0
    cfg.members[4].priority = 0;
    cfg.members[5].votes = 0
    cfg.members[5].priority = 0;
  3. Use rs.reconfig() method to reconfigure the replica set with the updated replica set configuration document.


Place voting members so that your designated primary or primaries can reach a majority of votes in the event of a network partition.

When updating the replica configuration object, access the replica set members in the members array with the array index. The array index begins with 0. Do not confuse this index value with the value of the members[n]._id field in each document in the members array.


  • The rs.reconfig() shell method can force the current primary to step down, which causes an election. When the primary steps down, the mongod closes all client connections. While this typically takes 10-20 seconds, try to make these changes during scheduled maintenance periods.
  • Avoid reconfiguring replica sets that contain members of different MongoDB versions as validation rules may differ across MongoDB versions.

In general and when possible, all members should have only 1 vote. This prevents intermittent ties, deadlocks, or the wrong members from becoming primary. Use members[n].priority to control which members are more likely to become primary.