Avoid Arbiters!

In the material “Lecture: MongoDB Replica Set” video at approximately 6:49 the instructor states to avoid arbiters because they can lead to data inconsistency. There is no explanation given for this statement beyond personal opinion. Can someone provide more information about in which situations this can occur, or share any bad experiences.

I’m assuming that using a secondary in place of an arbiter results in a more reliable topology.

Thanks for the info.

Hi @MongoStu,

Here is my reply over the same topic.

Let me know if it helps!


Thanks for the response.

A replica set is there to provide enhanced accessibility, so running an arbiter on the same host as a data-bearing node would definitely be of no advantage.

Based on the lecture, there seemed to be some other reasons to avoid using an arbiter. I guess only the instructor could fully explain the rationale.

Arbiters are mongod instances that are part of a replica set but do not hold data. Arbiters participate in elections in order to break ties. If a replica set has an even number of members, add an arbiter . Arbiters have minimal resource requirements and do not require dedicated hardware.You can deploy an arbiter on an application server or a monitoring host.

Do not run an arbiter on systems that also host the primary or the secondary members of the replica set. An arbiter does not store data, but until the arbiter’s process is added to the replica set, the arbiter will act like any other mongod process and start up with a set of data files and with a full-sized journal

Thanks for responding.

One of the best use cases for arbiters is when using multiple data centres, as described https://docs.mongodb.com/manual/core/replica-set-architecture-geographically-distributed/index.html.

I wonder if the another reason to avoid Arbiter on older versions could potentially be more security related - given you cannot necessarily login to an arbiter as it holds no user info i.e. no system.users collection

Therefore it is possible to “use admin” and simply “db.shutdownServer()” the arbiter (SERVER-5479)

RE data consistency, I did notice this in the online doc (https://docs.mongodb.com/manual/tutorial/add-replica-set-arbiter/)


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