M103 chapter 2 - Arbiter contribution to majority

[Stennie_X (Stennie)]

Hi @Rhonda_Tawasha,

@Rhonda_Tawasha

“An arbiter does not store data, but until the arbiter’s mongod process is added to the replica set, the arbiter will act like any other mongod process and start up with a set of data files and with a full-sized journal.”
It sounds like tha arbiter’s process isn’t immediately added to RS. Why is that?

When a mongod process destined to be an arbiter is first started, a role in the replica set configuration has not been established yet. There is no mongod option for declaring an arbiter role: this can only be set via the replica set configuration.

@Rhonda_Tawasha

Bottom line, does an arbiter count toward the write-commit majority, if so, under what situation(s)?

An arbiter is a voting-only replica set member that does not replicate any data and cannot contribute to acknowledgement of committed writes (or the write majority).

However, an arbiter can contribute a vote toward the voting majority required to elect or sustain a primary.

The difference between the two notions of majority is problematic in some scenarios, such as that described in the “Mitigate performance issues with PSA replica set” article you referenced. An arbiter can vote to elect or sustain a primary in a PSA replica set where one data-bearing member is unavailable or lagging, but the majority commit point will not be able to advance until a majority of data-bearing members are able to acknowledge writes.

For more robust deployments I recommend avoiding using an arbiter whenever possible. For more background please see Replica set with 3 DB Nodes and 1 Arbiter - #8 by Stennie_X.

Regards,
Stennie