diff --git a/source/core/replication-introduction.txt b/source/core/replication-introduction.txt new file mode 100644 index 00000000000..098ddb83f45 --- /dev/null +++ b/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 ` 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 `. 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 `. 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 `. Hidden members + provide reporting, dedicated backups, and dedicated read-only testing + and integration support. + +- :ref:`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`. \ No newline at end of file diff --git a/source/replication.txt b/source/replication.txt index 63462d26d21..d707933c591 100644 --- a/source/replication.txt +++ b/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: