Databases Reference
In-Depth Information
Failover and Primary Election
If the current primary fails, the rest of the nodes in the set will attempt to elect a new
primary node. This election process will be initiated by any node that cannot reach the
primary. The new primary must be elected by a
majority
of the nodes in the set. Arbiter
nodes participate in voting as well and are useful for breaking ties (e.g., when the par-
ticipating nodes are split into two halves separated by a network partition). The new
primary will be the node with the highest priority, using freshness of data to break ties
between nodes with the same priority (see Figures
9-6
,
9-7
, and
9-8
).
The primary node uses a heartbeat to track how many nodes in the cluster are visible
to it. If this falls below a majority, the primary will automatically fall back to secondary
status. This prevents the primary from continuing to function as such when it is sepa-
rated from the cluster by a network partition.
Whenever the primary changes, the data on the new primary is assumed to be the most
up-to-date data in the system. Any operations that have been applied on any other
nodes (i.e., the former primary node) will be rolled back, even if the former primary
comes back online. To accomplish this rollback, all nodes go through a resync process
when connecting to a new primary. They look through their oplog for operations that
have not been applied on the primary and query the new primary to get an up-to-date
copy of any documents affected by such operations. Nodes that are currently in the
process of resyncing are said to be
recovering
and will not be eligible for primary election
until the process is complete.
Figure 9-6. A replica set can have several servers of different priority levels
