Cygni replica set intro

source/core/replication-introduction.txt

@@ -0,0 +1,68 @@
+========================
+Replica Set Introduction
+========================
+
+.. default-domain:: mongodb
+
+A :term:`replica set` is a group of :program:`mongod` instances
+configured as a master that receives writes and one or more slaves that
+replicate data. Replica sets provide automatic failover in the event of
+an outage. If a master becomes unavailable, the replica set
+automatically promotes a slave.
+
+Replica sets provide strict consistency for reads
+from the master, , and allow you to
+spread database reads across machines, providing increased read
+capacity, as described in :doc:`/core/read-preference`. Replica sets
+allow asynchronous replication of writes, as described in
+:ref:`write-concern`. Most production deployments use replication.
+
+Replication
+-----------
+
+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.
+
+MongoDB applies database operations on the primary and records the
+operations in the primary's :term:`oplog`. Each replica set member
+maintains a copy of the oplog, which allow the member to apply
+replicated operations asynchronously.
+
+Failover and Recovery
+---------------------
+
+If a primary becomes unavailable, MongoDB can automatically failover and
+promote one of the secondaries as the new primary, automatically without
+administration intervention. The data on the new primary is now the most
+current in the set. All members resynchronize when connecting to the new
+primary. If the original primary comes back up, it does so as a
+secondary and begins syncing off the new primary. For more information,
+see :ref:`failover`.
+
+Member Configurations
+---------------------
+
+Replica sets provide the following configurable, special-purpose
+members:
+
+- :ref:`Arbiters <replica-set-arbiters>`. Arbiters have no data and
+  exist solely to participate in elections for primary and to break ties
+  for sets that have even numbers of members.
+
+- :ref:`Non-voting members <replica-set-non-voting-members>`. Non-voting
+  members are used only in sets with more than 12 members. The maximum
+  number of voting members in a set is 12.
+
+- :ref:`Hidden members <replica-set-hidden-members>`. Hidden members
+  provide reporting, dedicated backups, and dedicated read-only testing
+  and integration support.
+
+- :ref:`Delayed members <replica-set-delayed-members>`. Delayed members
+  copy and apply operations from the primary's oplog but with a
+  specified delay and can help recover data loss from human error.
+
+For more information on member configurations, see
+:ref:`replica-set-member-configuration`.

source/replication.txt

@@ -10,6 +10,11 @@ Replica Set Use and Operation
 
 Consider these higher level introductions to replica sets:
 
+.. toctree::
+   :hidden:
+
+   /core/replication-introduction
+
 .. toctree::
    :titlesonly: