Databases Reference
In-Depth Information
There are several different types of nodes that can coexist in a replica set:
standard
This is a regular replica set node. It stores a full copy of the data being replicated,
takes part in voting when a new primary is being elected, and is capable of becoming
the primary node in the set.
passive
Passive nodes store a full copy of the data and participate in voting but will never
become the primary node for the set.
arbiter
An arbiter node participates only in voting; it does not receive any of the data being
replicated and cannot become the primary node.
The difference between a standard node and a passive node is actually more of a sliding
scale; each
participating node
(nonarbiter) has a
priority
setting. A node with priority
0
is passive and will never be selected as primary. Nodes with nonzero priority will be
selected in order of decreasing priority, using freshness of data to break ties between
nodes with the same priority. So, in a set with two priority
1
nodes and a priority
0.5
node, the third node will be elected primary only if neither of the priority
1
nodes are
available.
Standard and passive nodes can be configured as part of a node's description, using the
priority
key:
> members.push({
... "_id" : 3,
... "host" : "morton:10003",
... "priority" : 40
... });
The default priority is 1, and priorities must be between 0 and 1000 (inclusive).
Arbiters are specified using the
"arbiterOnly"
key.
> members.push({
... "_id" : 4,
... "host" : "morton:10004",
... "arbiterOnly" : true
... });
There is more information about arbiters in the next section.
Secondary nodes will pull from the primary node's oplog and apply operations, just
like a slave in a master-slave system. A secondary node will also write the operation to
its own local oplog, however, so that it is capable of becoming the primary. Operations
in the oplog also include a monotonically increasing ordinal. This ordinal is used to
determine how up-to-date the data is on any node in the cluster.
