Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

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

Suppose a replication set R1 contains one primary, 2 secondary and one arbiter node. Voting will happen if the primery node goes down. Based on what criteria secondary members will vote to select the next primary node? Is the voting random process ? Whether the members will check the health / efficiency of the other members before voting?

Consider all the nodes have same priority and no salve delay

share|improve this question

migrated from Sep 13 '13 at 5:24

This question came from our site for professional and enthusiast programmers.

up vote 2 down vote accepted

Replica Set Elections

The MongoDB manual describes Replica Set Elections and the associated election mechanics such as Vetoes in detail.

Broadly speaking, the criteria for electing a node as primary includes:

  • Is that node currently in PRIMARY or SECONDARY state?

  • Is that node eligible to become primary (priority > 0)?

  • Do a majority of the nodes of the replica set see that memory as available (by way of replica set heartbeat)?

  • Does that node have the least replication lag in relation to the current primary?

  • Is that node the highest priority eligible node?

  • Would the node veto itself if elected primary? For example, if you step down a primary it will veto itself for election for 60 seconds by default.

The first node to receive a majority of votes subject to the election mechanics will become primary.

There are some further subtleties to the process depending what triggered the election (i.e. a unplanned failover versus stepping down the current primary).

Suppose a replication set R1 contains one primary, 2 secondary and one arbiter node.

In order to ensure consensus can be reached by a strict majority of voting nodes, the general recommendation is to have an odd number of voting nodes. With your example configuration an arbiter node is not required, and you should instead only have the primary and two secondaries. An arbiter node does not have any special role in the election process aside from being available to cast a vote.

With all things being equal (no replication lag, default priorities, no network issues, etc) your two secondaries in this scenario are equally likely to be elected primary in the event the current primary unexpectedly fails.

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.