Why we need to use Odd number of nodes in MongoDB ReplicaSet

In MongoDB ReplicaSet, the voting is done by a majority of voting members. Imagine a Replica Set with three (voting) members. Let’s say that Node A is primary, and nodes B+C are secondaries. Node A goes down, so nodes B+C go to election. They still do form a majority (two out of three). The election is first decided by priority. If both Nodes B & C have the same priority, then the one who is most up to date in respect to the failed primary (oplog) wins. Let’s say it’s Node B. Once node A comes back alive, there is no new election. Node B remains the master, and C+A are now secondaries. On the other hand, if two nodes go down you don’t have a majority, so the replica set can’t accept updates (apply writes) anymore until at least one of the two failing servers becomes alive (and connected by the single surviving node) again. Imagine now a Replica Set with four (voting) members. Let’s say that Node A is primary, and nodes B+C+D are secondaries. Node A goes down, so nodes B+C+D go to election. They of course form majority (three out of four) However, if two nodes go down you don’t have a majority (two out of four), so the replica set is again at read-only mode. So that’s why an odd number is recommended; If you loose a single member in a 3 members replica set, it’s the same as loosing a single member in a 4 members replica set: you still gain quorum majority and a new primary can be elected (the RS can still elect a new master by majority). On the other hand, if you loose two members in a 3 members replica set or a 4 members replica set (or n/2 members of n-members replica set) – again – the impact is the same: No new leader can be voted by election. So, to make a long story short, there is no redundancy gain by having an even number of members in a replica set. Read More:https://kovidacademy.com/blog/need-use-odd-number-nodes-mongodb-replicaset/