content_image/835637.jpg
Priority 0 Members as Standbys A priority 0 member can function as a standby. In some replica sets, it might not be possible to add a new member in a reasonable amount of time. A standby member keeps a current copy of the data to be able to replace an unavailable member. 

In many cases, you need not set standby to priority 0 . However, in sets with varied hardware or geographic distribution (page 579), a priority 0 standby ensures that only qualified members become primary. 

A priority 0 standby may also be valuable for some members of a set with different hardware or workload profiles. In these cases, deploy a member with priority 0 so it can’t become primary. Also consider using an hidden member (page 569) for this purpose. 

If your set already has seven voting members, also configure the member as non-voting (page 583). 

Priority 0 Members and Failover When configuring a priority 0 member, consider potential failover patterns, including all possible network partitions. Always ensure that your main data center contains both a quorum of voting members and contains members that are eligible to be primary. 

Configuration To configure a priority 0 member, see Prevent Secondary from Becoming Primary (page 621). 

## Hidden Replica Set Members 

A hidden member maintains a copy of the primary’s data set but is invisible to client applications. Hidden members are good for workloads with different usage patterns from the other members in the replica set . Hidden members must always be priority 0 members (page 567) and so cannot become primary . The db.isMaster() method does not display hidden members. Hidden members, however, may vote in elections (page 580). 

In the following five-member replica set, all four secondary members have copies of the primary’s data set, but one of the secondary members is hidden. 

<img src='content_image/835637.jpg'>

## Behavior 

Read Operations Clients will not distribute reads with the appropriate read preference (page 588) to hidden mem- bers. As a result, these members receive no traffic other than basic replication. Use hidden members for dedicated tasks such as reporting and backups. Delayed members (page 570) should be hidden. 

In a sharded cluster, mongos do not interact with hidden members. 

