Replica Set Arbiter

On this page

• Example
• Security

An arbiter doesnothave a copy of data set andcannotbecome a primary. Replica sets may have arbiters to add a vote inelections for primary. Arbiters_always_have exactly1election vote, and thus allow replica sets to have an uneven number of voting members without the overhead of an additional member that replicates data.

IMPORTANT

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

To add an arbiter, seeAdd an Arbiter to Replica Set.

WARNING

In general, avoid deploying more than one arbiter per replica set.

For the following MongoDB versions,pv1increases the likelihood ofw:1rollbacks compared topv0for replica sets with arbiters:

• MongoDB 3.4.1
• MongoDB 3.4.0
• MongoDB 3.2.11 or earlier

SeeReplica Set Protocol Versions.

Example

For example, in the following replica set, an arbiter allows the set to have an odd number of votes for elections:

Security

Authentication

When running withauthorization, arbiters exchange credentials with other members of the set to authenticate viakeyfiles. MongoDB encrypts the authentication process. 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 thelocalhost exception.

Communication

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. SeeConfigure mongod and mongos for TLS/SSLfor more information.

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