Hidden Replica Set Members

On this page

• Behavior
• Further Reading

A hidden member maintains a copy of theprimary’sdata set but isinvisibleto client applications. Hidden members are good for workloads with different usage patterns from the other members in thereplica set. Hidden members must always bepriority 0 membersand socannot become primary. Thedb.isMaster()method does not display hidden members. Hidden members, however,may voteinelections.

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.

Behavior

Read Operations

Clients will not distribute reads with the appropriateread preferenceto hidden members. As a result, these members receive no traffic other than basic replication. Use hidden members for dedicated tasks such as reporting and backups.Delayed membersshould be hidden.

In a sharded cluster,mongosdo not interact with hidden members.

Voting

Hidden members_may_vote in replica set elections. If you stop a voting hidden member, ensure that the set has an active majority or theprimarywill step down.

For the purposes of backups,

• If using the MMAPv1 storage engine, you can avoid stopping a hidden member with thedb.fsyncLock()anddb.fsyncUnlock()operations to flush all writes and lock themongodinstance for the duration of the backup operation.

• Changed in version 3.2:db.fsyncLock()can ensure that the data files do not change for MongoDB instances using either the MMAPv1 or the WiredTiger storage engines, thus providing consistency for the purposes of creating backups.

  In previous MongoDB versions,db.fsyncLock()_cannot_guarantee a consistent set of files for low-level backups (e.g. via file copycp,scp,tar) for WiredTiger.

Further Reading

For more information about backing up MongoDB databases, seeMongoDB Backup Methods. To configure a hidden member, seeConfigure a Hidden Replica Set Member.