CODEWITHSUNDEEP
mongodbdatabase-replication
Dan Dascalescu
Dan Dascalescu

Reputation: 152095

Why is an arbiter needed for an election in a primary - secondary - arbiter MongoDB replica set?

Mongo docs list this three-member configuration: primary, secondary, arbiter, as the minimal architecture of a replica set.

Why would an arbiter be necessary there? If the primary fails, the secondary won't see the heartbeat, so it needs to become primary. In other words, why wouldn't a primary + secondary configuration be sufficient? This related question doesn't seem to address the issue, as it discusses larger numbers of nodes.

Upvotes: 0

Views: 1324

Answers (2)

Sammaye
Sammaye

Reputation: 43884

If you bring the Arbiter down to its core it is essentially a none-data holding member used for voting.

One case for an Arbiter is as I state in the linked question: Why do we need an 'arbiter' in MongoDB replication? to break the problems of CAP but that is not its true purpose since you could easily replace that Arbiter with a data holding node and have the same effect.

However, an Arbiter will have a few benefits:

  • Small footprint
  • No data
  • No need to synch
  • can instantly vote
  • can be put literally anywhere in your network, app server or even another secondary to boost that part of your network (this comes into partitions).

So an Arbiter is extremely useful, even on one side of a partition (i.e. you have no partitioning in your network).

Now to explain base setup. An Arbiter would NOT be required, you could factor it out for a data holding node, but 3 data holding nodes is not the minimum (that is the minimum you need to keep automatic failover), 2 data holding nodes and 1 Arbiter is actually the minimum.

Now to answer:

In other words, why wouldn't a primary + secondary configuration be sufficient?

Because if one of those goes down there is only 50% of the vote left (2-1 = 1) and 50% is not classed as a sufficient majority for MongoDB to actually vote in a member (judged by the total configured voteable members in your rs.config).

Also in this case MongoDB does not actually know if that last member is the last member. It needs other members to tell it otherwise.

So yes, this is why you need a third guy.

Upvotes: 1

Enrique Fueyo
Enrique Fueyo

Reputation: 3488

Suppose you have only two servers, one primary and one secondary.

If suddenly the secondary can not reach the primary server it could be that the primary is down (in that case the secondary should become primary) but it could be as well a network issue that isolated the secondary (this the secondary is the one that is in deed down).

however, if you have an arbiter and the secondary cannot reach the primary but it CAN reach the arbiter then the issue is with the primary so it must become the new primary. If it CANNOT reach the primary, nor the arbiter, then the secondary knows that the issue is that he is isolated/broken -poor secondary :(- so he must not become the primary

Upvotes: 2

Related Questions