mongodb · steveren · Jun 20, 2016
diff --git a/source/core/distributed-write-operations.txt b/source/core/distributed-write-operations.txt
@@ -61,5 +61,5 @@ and apply the operations to themselves in an asynchronous process.
 .. include:: /images/replica-set-read-write-operations-primary.rst
 
 For more information on replica sets and write operations, see
-:doc:`/core/replication-introduction` and
+:doc:`/replication` and
 :doc:`/reference/write-concern`.
diff --git a/source/core/replication-process.txt b/source/core/replication-process.txt
diff --git a/source/faq/replica-sets.txt b/source/faq/replica-sets.txt
@@ -20,7 +20,7 @@ the :doc:`complete list of FAQs </faq>` or post your question to the
 What kinds of replication does MongoDB support?
 -----------------------------------------------
 
-MongoDB supports :doc:`replica sets </core/replication-introduction>`.
+MongoDB supports :doc:`replica sets </replication>`.
 
 .. versionchanged:: 3.0.0
 
@@ -36,7 +36,7 @@ What does the term "primary" mean?
 ----------------------------------
 
 :term:`Primary` is a :doc:`replica set
-</core/replication-introduction>` member that can accept writes. Only
+</replication>` member that can accept writes. Only
 the primary can accept write operations. [#edge-cases-2-primaries]_
 
 .. [#edge-cases-2-primaries]
@@ -47,7 +47,7 @@ What does the term "secondary" mean?
 ------------------------------------
 
 :term:`Secondary` nodes are the read-only nodes in :doc:`replica sets
-</core/replication-introduction>`. 
+</replication>`. 
 
 How long does replica set failover take?
 ----------------------------------------

diff --git a/source/includes/fact-csrs-versionchanged.rst b/source/includes/fact-csrs-versionchanged.rst
@@ -1,5 +1,5 @@
 Starting in MongoDB 3.2, config servers for sharded clusters can be
-deployed as a :doc:`replica set </core/replication-introduction>`.
+deployed as a :doc:`replica set </replication>`.
 Using a replica set for the config servers improves consistency across
 the config servers, since MongoDB can take advantage of the standard
 replica set read and write protocols for the config data. In addition,

diff --git a/source/includes/fact-mirrored-config-servers-deprecated.rst b/source/includes/fact-mirrored-config-servers-deprecated.rst
@@ -1,5 +1,5 @@
 Starting in MongoDB 3.2, config servers for sharded clusters can be
-deployed as a :doc:`replica set </core/replication-introduction>`. The
+deployed as a :doc:`replica set </replication>`. The
 replica set config servers must run the :doc:`WiredTiger storage engine
 </core/wiredtiger>`. MongoDB 3.2 deprecates the use of three mirrored
 :program:`mongod` instances for config servers.
diff --git a/source/includes/introduction-deploy-replica-set.rst b/source/includes/introduction-deploy-replica-set.rst
@@ -20,7 +20,7 @@ read operations. Replica sets should always have an odd number of
 members. This ensures that :doc:`elections
 </core/replica-set-elections>` will proceed smoothly. For more about
 designing replica sets, see :doc:`the Replication overview
-</core/replication-introduction>`.
+</replication>`.
 
 The basic procedure is to start the :program:`mongod` instances that
 will become members of the replica set, configure the

diff --git a/source/introduction.txt b/source/introduction.txt
@@ -60,14 +60,14 @@ operations </crud>` as well as:
 High Availability
 ~~~~~~~~~~~~~~~~~
 
-MongoDB's replication facility, called :ref:`replica set
-<replication-introduction>`, provides:
+MongoDB's replication facility, called :doc:`replica set
+</replication>`, provides:
 
 - *automatic* failover and
 
 - data redundancy.
 
-A :ref:`replica set <replication-introduction>` is a group of
+A :doc:`replica set </replication>` is a group of
 MongoDB servers that maintain the same data set, providing redundancy
 and increasing data availability.
 

diff --git a/source/reference/glossary.txt b/source/reference/glossary.txt
@@ -271,7 +271,7 @@ Glossary
       For a single :program:`mongod` server, a write operation is
       considered durable when it has been written to the server's
       :term:`journal` file. For a :doc:`replica set
-      </core/replication-introduction>`, a write operation is
+      </replication>`, a write operation is
       considerable durable once the write operation is durable on a
       :writeconcern:`majority of voting nodes <"majority">` in the
       replica set; i.e. written to a majority of voting nodes' journal

diff --git a/source/reference/write-concern.txt b/source/reference/write-concern.txt
@@ -17,7 +17,7 @@ Write Concern
 
 Write concern describes the level of acknowledgement requested from
 MongoDB for write operations to a standalone :program:`mongod` or to
-:doc:`replica sets </core/replication-introduction>` or to
+:doc:`replica sets </replication>` or to
 :doc:`sharded clusters </core/sharding-introduction>`. In
 sharded clusters, :program:`mongos` instances will pass the write
 concern on to the shards.

diff --git a/source/release-notes/2.2.txt b/source/release-notes/2.2.txt
@@ -668,7 +668,7 @@ behavior.
 Replica Set Members will not Sync from Members Without Indexes Unless ``buildIndexes: false``
 `````````````````````````````````````````````````````````````````````````````````````````````
 
-.. the following has been copied to source/core/replication-internals.txt
+.. the following has been copied to source/replication-internals.txt
 
 To prevent inconsistency between members of replica sets, if the
 member of a replica set has
@@ -681,7 +681,7 @@ unless they also have
 New Option To Configure Index Pre-Fetching during Replication
 `````````````````````````````````````````````````````````````
 
-.. the following has been copied to source/core/replication-internals.txt
+.. the following has been copied to source/replication-internals.txt
 
 By default, when replicating options, :term:`secondaries <secondary>`
 will pre-fetch :ref:`indexes` associated with a query to improve replication

diff --git a/source/tutorial/migrate-config-servers-with-different-hostnames.txt b/source/tutorial/migrate-config-servers-with-different-hostnames.txt
@@ -17,7 +17,7 @@ Migrate Config Servers with Different Hostnames
 
    .. versionchanged:: 3.2
       Starting in MongoDB 3.2, config servers can be deployed as
-      :doc:`replica set </core/replication-introduction>`.
+      :doc:`replica set </replication>`.
       MongoDB 3.2 deprecates the use of three mirrored :program:`mongod`
       instances for config servers.
 

diff --git a/source/tutorial/migrate-config-servers-with-same-hostname.txt b/source/tutorial/migrate-config-servers-with-same-hostname.txt
@@ -16,7 +16,7 @@ Migrate Config Servers with the Same Hostname
    mirrored :program:`mongod` instances as config servers.
 
    Starting in MongoDB 3.2, config servers can be deployed as :doc:`replica
-   set </core/replication-introduction>`. MongoDB 3.2
+   set </replication>`. MongoDB 3.2
    deprecates the use of three mirrored :program:`mongod` instances for
    config servers.
 

diff --git a/source/tutorial/recover-data-following-unexpected-shutdown.txt b/source/tutorial/recover-data-following-unexpected-shutdown.txt
@@ -37,7 +37,7 @@ To ensure a clean shut down, use one of the following methods:
 * On Linux, the :option:`mongod --shutdown` option.
 
 .. seealso:: The :doc:`/administration` documents, including
-   :ref:`Replica Set Syncing <replica-set-syncing>`, and the
+   :doc:`Replica Set Syncing </core/replica-set-sync>`, and the
    documentation on the :option:`--repair <mongod --repair>`
    :setting:`~storage.repairPath` and
    :setting:`storage.journal.enabled` settings.
@@ -59,7 +59,8 @@ When you are aware of a :program:`mongod` instance running without
 journaling that stops unexpectedly **and** you're not running with
 replication, you should always run the repair operation before
 starting MongoDB again. If you're using replication, then restore from
-a backup and allow replication to perform an initial :ref:`sync <replica-set-syncing>` to restore data.
+a backup and allow replication to perform an initial 
+:doc:`Replica Set Syncing </core/replica-set-sync>` to restore data.
 
 If the ``mongod.lock`` file in the data directory specified by
 :setting:`~storage.dbPath`, ``/data/db`` by default, is *not* a zero-byte file,

diff --git a/source/tutorial/resync-replica-set-member.txt b/source/tutorial/resync-replica-set-member.txt
@@ -50,10 +50,10 @@ Automatically Sync a Member
 .. warning:: During initial sync, :program:`mongod` will remove the
    content of the :setting:`~storage.dbPath`.
 
-This procedure relies on MongoDB's regular process for :ref:`initial
-sync <replica-set-initial-sync>`. This will store the current data on
+This procedure relies on MongoDB's regular process for 
+:doc:`Replica Set Syncing </core/replica-set-sync>`. This will store the current data on
 the member. For an overview of MongoDB initial sync process, see the
-:ref:`replica-set-syncing` section.
+:doc:`Replica Set Syncing </core/replica-set-sync>` section.
 
 If the instance has no data, you can simply follow the
 :doc:`/tutorial/expand-replica-set` or