Skip to content

cygni - replication intro #936

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions source/core/replication-introduction.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
========================
Replication Introduction
========================

.. default-domain:: mongodb

Replication maintains identical copies of an entire database instance on
multiple distinct systems. With multiple copies of the data, replication
makes the deployment resilient with regards to the loss of any
particular copy or instance. All MongoDB production deployments use
replication.

Replicated data helps ensure that all changes to a data set survive
failure. Replication also increases theoretical throughput. With
replication, if applications do not need to write data they can read
data from secondary databases, which increases read capacity.

MongoDB provides replication by storing the database in one location,
called a *primary*, and copying the database to multiple additional
locations, called *secondaries*. This configuration is called a
``replica set``. Each replica set has a :term:`primary` and one or more
:term:`secondaries <secondary>`. The primary is the only member of the
set that accepts write operations.

Replica Set Architecture
------------------------

A replica set consists of at least three :program:`mongod` instances: a
:term:`primary` and either two :term:`secondaries <secondary>` or a
secondary and an :term:`arbiter`. The primary accepts all writes for the
set. All members accept reads. Secondaries replicate from the primary by
asynchronously reading and applying the writes. This keeps the data on
the primary consistent. The replication process is asynchronous.
Secondaries replicate operations after the operations are applied to the
primary.

Failover and Recovery
---------------------

Replica sets provide automatic failover if the primary is not available.
In a failover situation, the replica set automatically promotes a
secondary to become the new primary, without user intervention. When the
original primary becomes available, it will rejoin the set as a
secondary.

For More Information
--------------------

For more information about replica sets, see :doc:`/replication`.