Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

According to Mongo documentation in order to safely deploy a replication set, you need at least two active and one arbiter because election of the a primary needs the majorities of the votes.

Let's say I'm able to have three machines, therefore deploy three full-blown mongo instances, no arbiter.

If the elected primary fails I end up with TWO nodes, where both of them has the same "power" level: for me this seems to be the must-aviod situation described at the deploy.

Can someone unfold why is it not a problem to elect a primary in this situation when it is if the initial setup is the same?

share|improve this question

Electing a primary in a two node set isn't a problem as long as both nodes are available. The rule is that the majority of the set needs to be up to successfully elect a primary.

In a two node set:

  • If both nodes are up, it can elect a primary
  • If only one node is up, it cannot see a majority and will remain read only

In a three node set:

  • If three nodes are up, one can become primary
  • If two nodes are up, one can become primary
  • If only one node is up, it's read only

A two node + arbiter set behaves just like a three node set, so if any one node (including the arbiter) fails, it can elect a primary.

It's important to realize that a set with only two voting nodes is running without write redundancy. You wouldn't want to create a set that always runs like that (hence, the arbiter), and you also want to recover a third node as soon as practically possible in the event of an outage.

share|improve this answer
This is OK, and thank you for the explanation, but I still don't have an answer why is it not a problem to elect from two nodes when one fails in a three-node setup and is when I do a two-node setup :) – petermolnar Mar 5 '13 at 9:23
actually, it does answer the question - 2/3 = majority, 2/2 = majority. The difference is that in a 3 node set if you lose a node you still have a fully functioning primary and a secondary, in a 2 node set if you lose a single node you are read only (no primary). You can run with 2 nodes, it just doesn't get you anything from a redundancy perspective - in fact you have made your system more likely to fail. – Adam C Mar 5 '13 at 11:22

In this case, you'd have hopefully set priorities on your nodes.

In testing, there seem to be other factors which are not as transparent, I have tested a 3 nodes replication set, and upon stepping down (and shutting down the nodes also), the nodes tend to take turns, first 1, then 2 then 3.

share|improve this answer

MongoDB replica sets use a basic leader election algorithm. If you have 3 nodes then you if you have atleast two functional nodes then you have a "quorum" and the cluster continues to operate fine. If you loose two nodes then you dont have "quorum" and leader election cannot proceed and the surviving replica is a in a read only state.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.