An odd number set is recommended. My doubt is as one goes down from an odd set, we have an even number set. The number of members fluctuate between even and odd when they go down one by one. We always don’t have odd member scenario. Can some one explain how MongoDB voting works?
-
normally a good way of solving this is to enter a abrtitar onto the application server specifically for voting – Sammaye Mar 24 '13 at 12:09
1 Answers
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) any more 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.
For more see election internals

- 18,687
- 5
- 58
- 72
-
2The key point is having no redundancy gain out of an even set up. I got it now. Thank you so much :) – Srik Mar 24 '13 at 12:40
-
Now one thing strikes my mind. The advantage of voting system being used in Mongo DB is also to increase availability. For example: In a 5 member setup, read only mode is reached when there are only two members left. And in a 11 member, its 5(>2). Am I right? – Srik Mar 24 '13 at 12:50
-
-
1I think I was having the same trouble understanding this. I figured if you have 3 nodes, and one went down, what's to stop the other 2 nodes from voting for themselves and causing a stalemate. After reading ur answer, I now suppose, that the only thing that matters is the ratio of live nodes to live + down nodes (or 2/3 in your example) since all live nodes will vote for the same node. Is that correct? – Squirrl Sep 27 '13 at 20:18
-
If optime and priority for all the replicas what happens then? Basically if you have a set of secondary nodes trying to elect a primary and all of them are in sync with the former primary and they all have the same priority will they just remain in stalemate? – Tiberiu Savin Nov 13 '13 at 17:06
-
@TiberiuSavin : If an even number of nodes are trying to vote for a new primary, even if they are all in sync with the latest entry in the oplog (=both can be elected) they will vote and make a choice : one of them is chosen at random. – Maxime Beugnet Jun 14 '16 at 16:25
-
1@Srik : Actually it's not entirely exact : A ReplicatSet can have up to 50 nodes but only 7 voting members. See here : https://docs.mongodb.com/manual/core/replica-set-elections/#non-voting-members. Thus, if you have 50 members, only 7 are voting. If you lose 4 of these voting members, you are in read only mode because you cannot reach anymore the majority of the voting members so you cannot start a voting round. – Maxime Beugnet Jun 14 '16 at 16:27
-
The other key point to consider is what happens in network splits. If you have an even number of nodes, say 6 nodes, and the network splits so they are neatly in two groups of 3, where the first three can't contact the second three, you have no majority - and you don't want one, because if 3 nodes could elect a new primary, you'd have two primaries. This is quite possible if you have the first 3 nodes in one datacenter (or AWS zone) and the second 3 in another. This is also where having a single arbiter, ideally in a third zone, is a good option to give you an odd number of nodes. – Korny Aug 02 '16 at 12:12
-