Introduction
...
The primary database receives all write operations. A replica set can have only one primary capable of confirming writes; although in some circumstances, another database may temporarily believe itself to also be primary. The primary records all changes to its data sets in its operation log: a groups of documents that keep a rolling record of all operations that modify the data stored in your databases. The secondary members then copy and apply these operations in an asynchronous process. All replica set members contain a copy of the operations log, which allows them to maintain the current state of the database.
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 non-responsive member as inaccessible. Heartbeats facilitate replications: any secondary member can import operation log entries from any other member it receives a heartbeat from.
...
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 operation log to its own data set in an asynchronous process. A replica set can have one or more secondaries.
...
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 low priority 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.
...
Must be low priority members. Set the priority to 0 to prevent a delayed member from becoming primary.
Should be hidden members. Always prevent applications from seeing and querying delayed members.
Can vote in elections for primary.
Must have a delay equal to or greater than your expected maintenance window durations.
Must have a delay smaller than the capacity of the operations logs.
In the following 5-member replica set, the primary and all secondaries have copies of the data set. One member applies operations with a delay of 3600 seconds (one hour). This delayed member is also hidden and is a priority 0 member:
...
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.
MongoDB Requirements
Storage Engine | Default Operations Log Size | Lower Bound | Upper Bound |
|---|---|---|---|
WiredTiger Storage Engine | 5% of free disk space | 990 MB | 50 GB |
MongoDB no longer supports 32-bit x86 platforms.
...
Related Information
| Filter by label (Content by label) | ||||||
|---|---|---|---|---|---|---|
|
...