Docs Menu

Replica Set Arbitericons/link.png

On this page

  • Example
  • Performance Issues with PSA replica sets
  • Replica Set Protocol Version and Arbiter
  • Security

In some circumstances (such as you have a primary and a secondary but cost constraints prohibit adding another secondary), you may choose to add an arbiter to your replica set. An arbiter does not have a copy of the data set and cannot become a primary. However, an arbiter participates in elections for primary. An arbiter has exactly 1 election vote.

Changed in version 3.6: Starting in MongoDB 3.6, arbiters have priority 0. When you upgrade a replica set to MongoDB 3.6, if the existing configuration has an arbiter with priority 1, MongoDB 3.6 reconfigures the arbiter to have priority 0.


Do not run an arbiter on systems that also host the primary or the secondary members of the replica set.

To add an arbiter, see Add an Arbiter to Replica Set.

For example, in the following replica set with a 2 data bearing members (the primary and a secondary), an arbiter allows the set to have an odd number of votes to break a tie:

Diagram of a replica set that consists of a primary, a secondary, and an arbiter.

If you are using a three-member primary-secondary-arbiter (PSA) architecture, the write concern "majority" can cause performance issues if a secondary is unavailable or lagging. See Mitigate Performance Issues with PSA Replica Set for advice on how to mitigate these issues.

For the following MongoDB versions, pv1 increases the likelihood of w:1 rollbacks compared to pv0 (no longer supported in MongoDB 4.0+) for replica sets with arbiters:

  • MongoDB 3.4.1
  • MongoDB 3.4.0
  • MongoDB 3.2.11 or earlier

See Replica Set Protocol Version.

When running with authorization, arbiters exchange credentials with other members of the set to authenticate. MongoDB encrypts the authentication process, and the MongoDB authentication exchange is cryptographically secure.

Because arbiters do not store data, they do not possess the internal table of user and role mappings used for authentication. Thus, the only way to log on to an arbiter with authorization active is to use the localhost exception.

The only communication between arbiters and other set members are: votes during elections, heartbeats, and configuration data. These exchanges are not encrypted.

However, if your MongoDB deployment uses TLS/SSL, MongoDB will encrypt all communication between replica set members. See Configure mongod and mongos for TLS/SSL for more information.

As with all MongoDB components, run arbiters in trusted network environments.

Give Feedback
MongoDB logo
© 2021 MongoDB, Inc.


  • Careers
  • Investor Relations
  • Legal Notices
  • Privacy Notices
  • Security Information
  • Trust Center
© 2021 MongoDB, Inc.