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 the mongod instance or instances that you wish to serve as primary can reach a majority of votes in the event of a network partition.

Use members[n].priority to control which members are more likely to become primary.

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.