Three-member replica set across Data center

[MaBeuLux88_xxx (Maxime Beugnet)]

Hi @Allwyn_Jesu,

There has been a number of topics already in this forum about arbiters. I’ll just mention this one below but please have a read through a few of them.

Replica Set with Master, Secondary, 3 Arbiters

To sum up: Having more than 1 arbiter is useless / doesn’t make sense. It’s not supported nor tested. It deteriorates the majority. MongoDB replica set maintain the “majority commit point” up to date which is the latest write operation that has been acknowledged by the majority of the data bearing nodes. If the majority commit point can’t move forward, the primary will keep 100% of the versions of 100% of the data in cache which will overflow at some point (swap). Even worst, ALL the data not …

Arbiters are not recommended in a production environment, it’s as simple as that. If you can, avoid them.

A MongoDB Replica Set (RS) can only elect a primary if the majority of the voting members in the RS can be reached. In your setup with 2 nodes in DC1 and 1 node in DC2, if DC1 goes down / offline, you are left with a single node that cannot reach the majority (2) so it cannot become primary. This is to prevent the possibility of having 2 primaries as the isolated DC1 is in a position to elect a primary potentially (== split brain).

The only way to get something “perfect” is to have 3 DCs, each with one node. As it’s complicated / costly to have, in MongoDB Atlas, we use the “availability zones” of AWS and make sure each node is in a different availability zone.

I also explained here a few hours ago why one arbiter is already a bad idea - even in a 5 nodes RS: readConcern with more than 1 secondary and an arbiter - #2 by MaBeuLux88.

I hope this helps .

Cheers,
Maxime.