Replication in MongoDB
A replica set is a group of MongoDB one or more MongoDB databases that maintain the same data set. A replica set contains several data bearing nodes databases and optionally one arbiter nodedatabase. Of the data bearing nodesdatabases, one and only one member is deemed the primary node, while the other nodes others are deemed secondary nodes.
The primary nodedatabase receives all write operations. A replica set can have only one primary capable of confirming writes; although in some circumstances, another database may transiently temporarily believe itself to also be primary. The primary records all changes to its data sets in its operation log, e.g. oplog.: a groups of documents that keep a rolling record of all operations that modify the data stored in your databases.
Replica set members send heartbeats (pings) to each other every two seconds. If a heartbeat does not return within 10 seconds, the other members mark the delinquent non-responsive member as inaccessible.
Replica Set Primary
The primary is the only member in the replica set that receives write operations. MongoDB applies write operations on the primary and then records the operations on the primary’s oplogoperation log. Secondary members replicate this log and apply the operations to their data sets.
In the following three-member replica set, the primary accepts all write operations. Then the secondaries replicate the oplog operation log data to apply to their data sets.
All members of the replica set can accept read operations. However, by default, an application directs its read operations to the primary member.
The replica set can have at most one primary. If the current primary becomes unavailable, an election determines the new primary.
In the following 3-member replica set, the primary becomes unavailable. This triggers an election which selects one of the remaining secondaries as the new primary.
After a replica set has a stable primary, the election algorithm will make the secondary with the highest priority available call an election. Member priority affects both the timing and the outcome of elections; secondaries with higher priority call elections relatively sooner than secondaries with lower priority, and are also more likely to win. However, a lower priority instance can be elected as primary for brief periods, even if a higher priority secondary is available. Replica set members continue to call elections until the highest priority member available becomes primary.
Replica Set Secondary
A secondary maintains a copy of the primary’s data set. To replicate data, a secondary applies operations from the primary’s oplog operation log to its own data set in an asynchronous process. A replica set can have one or more secondaries.
The following three-member replica set has two secondary members. The secondaries replicate the primary’s oplog and operation log and apply the operations to their data sets.
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.
In the following three-member replica set, the primary becomes unavailable. This triggers an election where one of the remaining secondaries becomes the new primary.
You can configure a secondary member for a specific purpose. You can configure a secondary to:
- Prevent it from becoming a primary in an election, which allows it to reside in a secondary data center or to serve as a cold standby.
- Prevent applications from reading from it, which allows it to run applications that require separation from normal traffic.
- Keep a running 'historical' snapshot for use in recovery from certain errors, such as unintentionally deleted databases. .
Replica Set Hidden
A hidden member maintains a copy of the primary’s data set but is invisible to client applications. Hidden members are good for workloads with different usage patterns from the other members in the replica set. Hidden members must always be priority 0 members and so cannot become primary. Hidden members, however, may vote in elections. Hidden members receive no traffic other than basic replication. Use hidden members for dedicated tasks such as reporting and backups.
In the following five-member replica set, all four secondary members have copies of the primary’s data set, but one of the secondary members is hidden.
Replica Set Arbiter
An arbiter does not have a copy of data set and cannot become a primary. Replica sets may have arbiters to add a vote in elections for primary. Arbiters always have exactly 1 election vote, and thus allow replica sets to have an uneven number of voting members without the overhead of an additional member that replicates data.
For example, in the following replica set, an arbiter allows the set to have an odd number of votes for elections:
- Authentication: when running authorisation, arbiters exchange credentials with other members of the set to authenticate via keyfiles. MongoDB encrypts the authentication process. The MongoDB authentication exchange is cryptographically secure.
- Communication: because arbiters do not store data, they do not possess the internal table of user and role mappings used for authentication. Thus, the only way to log on to an arbiter with authorisation active is to use the localhost exception. The only communication between arbiters and other set members are: votes during elections, heartbeats, and configuration data. These exchanges are not encrypted.
Related information
| Filter by label (Content by label) | ||||
|---|---|---|---|---|
|