Skip to content
Find file
Fetching contributors…
Cannot retrieve contributors at this time
160 lines (125 sloc) 6.2 KB
.. default-domain:: mongodb
.. contents:: On this page
:backlinks: none
:depth: 1
:class: singlecol
A *replica set* in MongoDB is a group of :program:`mongod` processes
that maintain the same data set. Replica sets provide redundancy and
high availability, and are the basis for all production deployments.
This section introduces replication in MongoDB as well as the
components and architecture of replica sets. The section also provides
tutorials for common tasks related to replica sets.
Redundancy and Data Availability
Replication provides redundancy and increases data availability. With
multiple copies of data on different database servers, replication
provides a level of fault tolerance against the loss of a single
database server.
In some cases, replication can provide increased read capacity as
clients can send read operations to different servers. Maintaining
copies of data in different data centers can increase data locality
and availability for distributed applications. You can also maintain
additional copies for dedicated purposes, such as disaster recovery,
reporting, or backup.
Replication in MongoDB
A replica set is a group of :program:`mongod` instances that maintain
the same data set. A replica set contains several data bearing nodes
and optionally one arbiter node. Of the data bearing nodes, one and
only one member is deemed the primary node, while the other nodes are
deemed secondary nodes.
The :doc:`primary node </core/replica-set-primary>` receives all write
operations. A replica set can have only one primary capable of
confirming writes with :writeconcern:`{ w: "majority" } <"majority">`
write concern; although in some circumstances, another mongod instance
may transiently believe itself to also be primary.
[#edge-cases-2-primaries]_ The primary records all changes to its data
sets in its operation log, i.e. :doc:`oplog
</core/replica-set-oplog>`. For more information on primary node
operation, see :doc:`/core/replica-set-primary`.
.. include:: /images/replica-set-read-write-operations-primary.rst
The :doc:`secondaries </core/replica-set-secondary>` replicate the
primary's oplog and apply the operations to their data sets such that
the secondaries' data sets reflect the primary's data set. If the
primary is unavailable, an eligible secondary will hold an election to
elect itself the new primary. For more information on secondary
members, see :doc:`/core/replica-set-secondary`.
.. include:: /images/replica-set-primary-with-two-secondaries.rst
You may add an extra :program:`mongod` instance to a replica set as an
:doc:`arbiter </core/replica-set-arbiter>`. Arbiters do not maintain a
data set. The purpose of an arbiter is to maintain a quorum in a
replica set by responding to heartbeat and election requests by other
replica set members. Because they do not store a data set, arbiters can
be a good way to provide replica set quorum functionality with a
cheaper resource cost than a fully functional replica set member with a
data set. If your replica set has an even number of members, add an
arbiter to obtain a majority of votes in an election for primary.
Arbiters do not require dedicated hardware. For more information on
arbiters, see :doc:`/core/replica-set-arbiter`.
.. include:: /images/replica-set-primary-with-secondary-and-arbiter.rst
An :doc:`arbiter </core/replica-set-arbiter>` will always be an arbiter
whereas a :doc:`primary </core/replica-set-primary>` may step down and
become a :doc:`secondary </core/replica-set-secondary>` and a
:doc:`secondary </core/replica-set-secondary>` may become the primary
during an election.
.. _asynchronous-replication:
Asynchronous Replication
Secondaries apply operations from the primary asynchronously. By
applying operations after the primary, sets can continue to function
despite the failure of one or more members. For more information on
replication mechanics, see :ref:`replica-set-oplog` and
Automatic Failover
When a primary does not communicate with the other members of the set
for more than 10 seconds, an eligible secondary will hold an election
to elect itself the new primary. The first secondary to hold an
election and receive a majority of the members' votes becomes primary.
.. include:: /includes/fact-replica-set-protocolVersion1.rst
.. include:: /images/replica-set-trigger-election.rst
See :ref:`replica-set-elections` and
:ref:`replica-set-rollbacks` for more information.
Read Operations
By default, clients read from the primary [#edge-cases-2-primaries]_;
however, clients can specify a :doc:`read preference
</core/read-preference>` to send read operations to secondaries.
:ref:`Asynchronous replication <asynchronous-replication>` to
secondaries means that reads from secondaries may return data that does
not reflect the state of the data on the primary. For information on
reading from replica sets, see :doc:`/core/read-preference`.
.. include:: /includes/extracts/concurrent-operations-read-uncommitted.rst
For more information on read isolations, consistency and recency for
MongoDB, see :doc:`/core/read-isolation-consistency-recency`.
Additional Features
Replica sets provide a number of options to support application
needs. For example, you may deploy a replica set with :doc:`members in
multiple data centers
</core/replica-set-architecture-geographically-distributed>`, or
control the outcome of elections by adjusting the
:rsconf:`members[n].priority` of some
members. Replica sets also support dedicated members for reporting,
disaster recovery, or backup functions.
See :ref:`replica-set-secondary-only-members`,
:ref:`replica-set-hidden-members` and
:ref:`replica-set-delayed-members` for more information.
.. [#edge-cases-2-primaries]
.. include:: /includes/footnote-two-primaries-edge-cases.rst
.. class:: hidden
.. toctree::
Something went wrong with that request. Please try again.