Replica Set Arbiter¶
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 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
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:
majority and Three-Member PSA¶
If you have a three-member replica set with a
primary-secondary-arbiter (PSA) architecture or a sharded cluster
with a three-member PSA shards, the cache pressure will increase if
any data bearing node is down and support for
"majority" read concern is enabled.
To prevent the storage cache pressure from immobilizing a deployment with a three-member primary-secondary-arbiter (PSA) architecture, you can disable read concern "majority" starting in MongoDB 4.0.3 (and 3.6.1+). For more information, see Disable Read Concern Majority.
Replica Set Protocol Version and Arbiter¶
For the following MongoDB versions,
pv1 increases the likelihood
w:1 rollbacks compared to
(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
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
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
mongos for TLS/SSL for more information.
As with all MongoDB components, run arbiters in trusted network environments.