1

I'm trying to get into ReplicaSet concept, and found something weird in mongoDB Documentation:

For a node to be elected primary, it must receive a majority of votes. This is a majority of all votes in the set: if you have a 5-member set and 4 members are down, a majority of the set is still 3 members (floor(5/2)+1). Each member of the set receives a single vote and knows the total number of available votes.

If no node can reach a majority, then no primary can be elected and no data can be written to that replica set (although reads to secondaries are still possible).

(taken from here)

So, If I got that right, in the 5-member case mentioned there the one node that's still standing WILL NOT be chosen as primary and the whole set will not get any writes? and that's even if this single node was the last primary before the elections?

If it's true there can be many less-radical cases which will end up with a degenerated set. How can we avoid this?

Community
  • 1
SecondThought
  • 409
  • 1
  • 4
  • 11
  • The design is in order to avoid a split-brain scenario, so that there aren't two divergent writable servers that each consider themselves the primary. Are you looking for ways to get around this by forcing the system to be writable without a majority of members? Or are you looking for ways to avoid this condition occurring in the first place? – Shane Madden May 31 '12 at 21:49
  • Let's say I have 3 nodes, could it be possible that when the primary gets down the others elect to one another and no one will become a primary? will they try to elect again until someone is elected? what happens if two of them are down? the remaining node will never be primary - I don't want my Set to ever lose it's primary. will a arbiter help here? – SecondThought Jun 07 '12 at 09:37
  • If two out of three are up they will elect one of them as primary. If they split the vote the first time, they will back off and renominate so while it may take more than one "vote" a new primary _will_ be elected. – Asya Kamsky Jul 01 '12 at 07:11

1 Answers1

2

The majority rule is intended to prevent multiple single (think isolated) nodes from claiming to be primary at the same time. The strategies to avoid this will be dependent on your architecture.

As some examples - you can have stand by arbiters in each data center or zone so you can add them to form a majority, you can reconfigure the set in the event of a "disaster" to only include 3 nodes instead of 5, thereby letting 2 form a majority etc. Or, you can restart the sole remaining mongod instance (if such a thing exists) as a standalone without replica set options and use it in that manner until you restore your set.

When designing for disaster recovery or failover across multiple zones, the important thing to do is keep the majority rule in mind as you are designing it.

Adam C
  • 5,222
  • 2
  • 30
  • 52