The minimum recommended configuration for a replica set is a three member replica set with three data-bearing members: one primary and two secondary members.
Primary
Secondary
Arbiter
The primary is the only member that receives all write operations.
MongoDB applies write operations on the primary and then records the operations on the primary's oplog. Secondary members replicate this log and apply the operations to their data sets.
All members of the replica set can accept read operations. by default, an application directs its read operations to the primary member.
The replica set can have at most one primary. [2] If the current primary becomes unavailable, an election determines the new primary.
Secondaries replicate operations from the primary to maintain an identical data set.
To replicate data, a secondary applies operations from the primary's oplog to its own data set in an asynchronous process.
A replica set can have one or more secondaries.
Although clients cannot write data to secondaries, clients can read data from secondary members.
A secondary can become a primary. If the current primary becomes unavailable, the replica set holds an election to choose which of the secondaries becomes the new primary.
An arbiter participates in elections for primary but an arbiter does not have a copy of the data set and cannot become a primary.
An arbiter has exactly 1 election vote. By default an arbiter has priority 0.