Priority 0 Replica Set Members

A priority 0 member is a member that cannot become primary and cannot trigger elections. Priority 0 members can acknowledge write operations issued with write concern of w : <number>. For "majority" write concern, the priority 0 member must also be a voting member (i.e. members[n].votes is greater than 0) to acknowledge the write. Non-voting replica set members (i.e. members[n].votes is 0) cannot contribute to acknowledging write operations with "majority" write concern.

Other than the aforementioned restrictions, secondaries that have priority 0 function as normal secondaries: they maintain a copy of the data set, accept read operations, and vote in elections.

Configuring a replica set member with priority 0 might be desired if the particular member is deployed in a data center that is distant from the main deployment and therefore has higher latency. It may serve local read requests well, but might not be an ideal candidate to perform the duties of a primary due to its latency.

For this situation, the following diagram shows a data center on the left which hosts the primary and a secondary, and a data center on the right which hosts a secondary that has been configured to have priority 0 to prevent it from becoming primary. Because of this setting, only the members in the left data center are eligible to become primary in an election.

Compare this to the default priority for replica set members, priority 1, where either of the secondaries in this scenario would be eligible to serve as primary. See Replica Sets Distributed Across Two or More Data Centers for more information.