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

Hidden Replica Set Members

On this page

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 and so cannot become primary. The db.isMaster() method does not display hidden members. Hidden members, however, may vote in elections.

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.

Diagram of a 5 member replica set with a hidden priority 0 member.


Read Operations

Clients will not distribute reads with the appropriate read preference to 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 members should be hidden.

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


Hidden members may vote in replica set elections. If you stop a voting hidden member, ensure that the set has an active majority or the primary will step down.

For the purposes of backups,

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

  • Changed in version MongoDB: 3.2

    db.fsyncLock() ensures that the data files are safe to copy using low-level backup utilities such as cp, scp, or tar. A mongod started using the copied files contains user-written data that is indistinguishable from the user-written data on the locked mongod.

    Prior to MongoDB 3.2, db.fsyncLock() cannot guarantee that WiredTiger data files are safe to copy using low-level backup utilities.

    The data files of a locked mongod may change due to operations such as journaling syncs or WiredTiger snapshots. While this has no affect on the logical data (e.g. data accessed by clients), some backup utilities may detect these changes and emit warnings or fail with errors. For more information on MongoDB- recommended backup utilities and procedures, see MongoDB Backup Methods.

Write Concern

Hidden replica set members can acknowledge write operations issued with w: <number>. For write operations isued with w : "majority", however, hidden members must also be voting members (i.e. members[n].votes greater than 0) to acknowledge the "majority" write operation. Non-voting replica set members (i.e. members[n].votes is 0) cannot contribute to acknowledging write operations with majority write concern.

Further Reading

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