Avoid Arbiters!

[MongoStu (Stuart Thompson)]

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.

[kanikasingla]

Hi @MongoStu,

Here is my reply over the same topic.

Why we are encouraged not to use arbiter?

Adding to @steevej-1495’s reply, arbiters can not become primary and is added to vote for elections in case of failover. We should be careful to not to host an arbiter on the same server as primary or secondary members of the replica set. Reason being if the server where your primary and arbiter is hosted goes down then you will also lose your majority voting which is why at the first place we keeps arbiter. Kanika

Let me know if it helps!

Kanika

[MongoStu (Stuart Thompson)]

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.

[Rafeeq_01820 (Rafeeq Badiger)]

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

[MongoStu (Stuart Thompson)]

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.

[Jonathan_90090 (Jonathan Saxon)]

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/)

NOTE

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