moved replication-introduction content up into replication.txt

Signed-off-by: kay <kay.kim@10gen.com>

config/sphinx_local.yaml

@@ -41,6 +41,7 @@ theme:
     - /core/replica-set-architectures
     - /core/replica-set-high-availability
     - /core/replica-set-members
+    - /replication
     - /core/sharded-cluster-components
     - /core/wiredtiger
     - /core/write-operations-atomicity

source/replication.txt

@@ -4,6 +4,12 @@ Replication
 
 .. default-domain:: mongodb
 
+.. contents:: On this page
+   :local:
+   :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.
@@ -15,14 +21,139 @@ tutorials for common tasks related to replica sets.
 
    You can download this section in PDF form as :hardlink:`Replication
    and MongoDB <MongoDB-replication-guide.pdf>`.
-
+
+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
+:ref:`replica-set-sync`.
+
+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::
     :titlesonly:
-
-    /core/replication-introduction	
+
     /core/replica-set-members
     /core/replica-set-oplog
     /core/replica-set-sync