DOCS-93: fixing build errors in sharding docs.

Author: Sam Kleinman

source/administration/sharding-architectures.txt

@@ -45,7 +45,7 @@ a production-level shard cluster should have the following:
   - 3 :program:`mongod` replicas or
 
     .. seealso:: ":doc:`/administration/replication-architectures`"
-       and ":doc:`/administration/replication`."
+       and ":doc:`/administration/replica-sets`."
 
   - 2 :program:`mongod` replicas and a single
     :program:`mongod` instance acting as a :term:`arbiter`.
@@ -55,8 +55,8 @@ a production-level shard cluster should have the following:
        All replica set configurations and options are available.
 
        You may also choose to deploy a :ref:`hidden member
-       <replica-set-hidden-member>` for backups or a
-       :ref:`delayed member <replica-set-delayed-member>`.
+       <replica-set-hidden-members>` for backups or a
+       :ref:`delayed member <replica-set-delayed-members>`.
 
        You might also keep a member of each replica set in a
        geographically distinct data center in case the primary data

source/administration/sharding.txt

@@ -28,9 +28,9 @@ Setup
 -----
 
 If you have an existing replica set, you can use then
-":doc:`/tutorials/convert-replica-set-to-replicated-shard-cluster`"
-tutorial as a guide. If you're deploying a :term:`shard
-cluster` from scratch, use the following procedure as a starting point:
+":doc:`/tutorial/convert-replica-set-to-replicated-shard-cluster`"
+tutorial as a guide. If you're deploying a :term:`shard cluster` from
+scratch, use the following procedure as a starting point:
 
 #. Provision the required hardware.
 
@@ -255,7 +255,7 @@ procedure:
 
 .. note::
 
-   It may take some time for :term:`chunks` to migrate to
+   It may take some time for :term:`chunks <chunk>` to migrate to
    the new shard.
 
    See the ":ref:`Balancing and Distribution <sharding-balancing>`"
@@ -269,7 +269,7 @@ Removing a Shard from a Cluster
 
 To remove a :term:`shard` from a :term:`shard cluster`, you must:
 
-- Begin moving :term:`chunks` off of the shard.
+- Begin moving :term:`chunks <chunk>` off of the shard.
 
 - Ensure that this shard is not the "primary" shard for any databases
   in the cluster. If it is, move the "primary" status for these databases to
@@ -726,7 +726,7 @@ Config Server Maintenance
 -------------------------
 
 Config servers store all shard cluster metadata, perhaps most notably,
-the mapping from :term:`chunks` to :term:`shards`.
+the mapping from :term:`chunks <chunk>` to :term:`shards <shard>`.
 This section provides an overview of the basic
 procedures to migrate, replace, and maintain these servers.
 
@@ -909,7 +909,7 @@ without one the config databases :program:`mongod` instances, creating
 a backup of the cluster metadata from the config database is very
 straightforward:
 
-#. Shut down one of the :term:`config databases`.
+#. Shut down one of the :term:`config databases <config database>`.
 
 #. Create a full copy of the data files (i.e. the path specified by
    the :setting:`dbpath` option for the config instance.
@@ -1059,7 +1059,7 @@ Disable Balancing During Backups
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If MongoDB migrates a chunk while you are taking a :doc:`backup
-</administration/backup>`, you can end with an inconsistent snapshot
+</administration/backups>`, you can end with an inconsistent snapshot
 of your shard cluster. You should never run a backup unless you're
 certain that you have disabled the balancer. There are two ways to
 ensure this:

source/core/sharding-internals.txt

@@ -22,8 +22,8 @@ Shard Keys
 ----------
 
 Shard keys are the field in a collection that MongoDB uses to
-distribute :term:`documents` within a sharded cluster. See the
-:ref:`overview of shard keys <sharding-shard-keys>` for an
+distribute :term:`documents <document>` within a sharded cluster. See the
+:ref:`overview of shard keys <sharding-shard-key>` for an
 introduction these topics.
 
 .. index:: shard key; cardinality
@@ -34,7 +34,7 @@ Cardinality
 
 In the context of MongoDB, cardinality, refers to the concept of
 counting or measuring the number of items in a set, represents the
-number of :term:`chunks` that MongoDB may partition the data into.
+number of :term:`chunks <chunk>` that MongoDB may partition the data into.
 
 For example, consider a collection of data such as an "address book"
 that stores address records:
@@ -129,7 +129,7 @@ that query sharded clusters and :program:`mongos` hides all of the
 complexity of data :term:`partitioning <partition>` from the
 application. A :program:`mongos` receives queries from applications,
 and then, using the metadata from the :ref:`config server
-<sharding-config-database>`, routes queries to the :program:`mongod`
+<sharding-config-server>`, routes queries to the :program:`mongod`
 instances that hold the appropriate the data. While the :program:`mongos`
 succeeds in making all querying operational in sharded environments,
 the :term:`shard key` you select can have a profound affect on query
@@ -258,19 +258,19 @@ member of the cluster is responsible for the same volume of data.
 
 This section contains complete documentation of the balancer process
 and operations. For a higher level introduction see
-the :ref:`Balancing <sharding-balancer>` section.
+the :ref:`Balancing <sharding-balancing>` section.
 
 Balancing Internals
 ~~~~~~~~~~~~~~~~~~~
 
 A balancing round originates from an arbitrary :program:`mongos`
 instance. Because your shard cluster can have a number of
 :program:`mongos` instances, when a balancer process is active it
-acquires a "lock" by modifying a document on the :term:`config server`.
+acquires a "lock" by modifying a document on the :term:`config database`.
 
 By default, the balancer process is always running. When the number of
 chunks in a collection is unevenly distributed among the shards, the
-balancer begins migrating :term:`chunks` from shards with a
+balancer begins migrating :term:`chunks <chunk>` from shards with a
 disproportionate number of chunks to shards with a fewer number of
 chunks. The balancer will continue migrating chunks, one at a time,
 until the data is evenly distributed among the shards (i.e. the
@@ -325,7 +325,7 @@ following effects:
 For many deployments it makes sense to avoid frequent and potentially
 spurious migrations at the expense of a slightly less evenly
 distributed data set, but this value is :ref:`configurable
-<sharding-modify-chunk-size>`. Be aware of the following limitations
+<sharding-balancing-modify-chunk-size>`. Be aware of the following limitations
 when modifying chunk size:
 
 - Automatic splitting only occurs when inserting :term:`documents

source/core/sharding.txt

@@ -112,6 +112,8 @@ If you do plan to eventually partition your data, you should also
 give some thought to which collections you'll want to shard along with
 the corresponding shard keys.
 
+.. _sharding-capacity-planning:
+
 .. warning::
 
    It takes time and resources to deploy sharding, and if your system
@@ -124,7 +126,7 @@ the corresponding shard keys.
    overcapacity to enable sharding.
 
 .. index:: sharding; requirements
-.. _sharding-requirements-infrastructure:
+.. _sharding-requirements:
 
 Requirements
 ------------
@@ -234,9 +236,9 @@ Shard Keys
 
 "Shard keys" refer to the :term:`field` that exists in every
 :term:`document` in a collection that that MongoDB uses to distribute
-documents among the :term:`shards`. Shard keys, like :term:`indexes`,
-can be either a single field, or may be a compound key, consisting of
-multiple fields.
+documents among the :term:`shards <shard>`. Shard keys, like
+:term:`indexes <index>`, can be either a single field, or may be a
+compound key, consisting of multiple fields.
 
 Remember, MongoDB's sharding is range-based: each :term:`chunk` holds
 documents having specific range of values for the "shard key". Thus,
@@ -316,10 +318,10 @@ server data is only read in the following situations:
 
 If all three config servers are inaccessible, you can continue to use
 the cluster as long as you don't restart the :program:`mongos`
-instances until the after config servers are accessible again. If
-the :program:`mongos` instances were restarted and there are no accessible
-config servers, they would be unable to direct queries or write operations
-to the cluster.
+instances until the after config servers are accessible again. If you
+restart the :program:`mongos` instances and there are no accessible
+config servers, the :program:`mongos` would be unable to direct
+queries or write operations to the cluster.
 
 Because the configuration data is small relative to the amount of data
 stored in a cluster, the amount activity is relatively low, and 100%
@@ -344,8 +346,7 @@ Operations
 The :program:`mongos` provides a single unified interface to a sharded
 cluster for applications using MongoDB. Except for the selection of a
 :term:`shard key`, application developers and administrators need not
-consider any of the :ref:`internal details of sharding
-<sharding-internals>.
+consider any of the :doc:`internal details of sharding <sharding-internals>`.
 
 :program:`mongos` caches data from the :ref:`config server
 <sharding-config-server>`, and uses this to route operations from

source/reference/glossary.txt

@@ -137,6 +137,10 @@ Glossary
       A distributed system architecture that splits data into ranges.
       :term:`Sharding` is a kind of partitioning.
 
+   split
+      The division between :term:`chunks <chunk>` in a :term:`shard
+      cluster`.
+
    mongod
       The program implemeting the MongoDB database server. This server
       typically runs as a :term:`daemon`.

source/sharding.txt

@@ -53,7 +53,6 @@ managing sharded clusters:
    :maxdepth: 1
 
    tutorial/deploy-shard-cluster
-   tutorial/convert-standalone-node-to-shard-cluster
    tutorial/add-shards-to-shard-cluster
    tutorial/remove-shards-from-cluster
 

source/tutorial.txt

@@ -32,7 +32,6 @@ Administration
    tutorial/expand-replica-set
    tutorial/recover-data-following-unexpected-shutdown
    tutorial/deploy-shard-cluster
-   tutorial/convert-standalone-node-to-shard-cluster
    tutorial/convert-replica-set-to-replicated-shard-cluster
    tutorial/add-shards-to-shard-cluster
    tutorial/remove-shards-from-cluster

source/tutorial/add-shards-to-shard-cluster.txt

@@ -22,11 +22,11 @@ cluster, you should always ensure that your cluster has enough
 capacity to support the migration without impacting legitimate
 production traffic.
 
-In production environments, all shards should be :term:`replica
-sets`. Furthermore, *all* interaction with your sharded cluster should
-pass through a :program:`mongos` instance, and this tutorial assumes
-that you already have a :program:`mongo` shell connection to a
-:program:`mongos` instance.
+In production environments, all shards should be :term:`replica sets
+<replica set>`. Furthermore, *all* interaction with your sharded
+cluster should pass through a :program:`mongos` instance, and this
+tutorial assumes that you already have a :program:`mongo` shell
+connection to a :program:`mongos` instance.
 
 Process
 -------
@@ -89,7 +89,7 @@ Repeat this step for each shards in your cluster.
 
 .. note::
 
-   It may take some time for :term:`chunks` to migrate to the new
+   It may take some time for :term:`chunks <chunk>` to migrate to the new
    shard, because the system must copy data from one :program:`mongod`
    instance to another while maintaining data consistency.
 

source/tutorial/deploy-shard-cluster.txt

@@ -18,7 +18,7 @@ Requirements
 ------------
 
 See the ":ref:`Requirements for Shard Clusters
-<sharding-requirements`" section for more information about potential
+<sharding-requirements>`" section for more information about potential
 requirements for sharded cluster.
 
 Procedure
@@ -163,11 +163,11 @@ Enable Sharding for Collections
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Finally, you may enable sharding on a per-collection basis. Because
-MongoDB uses :term:`range based sharding` you must specify a
-:term:`shard key` that MongoDB can use to distribute your documents
-among the shards. See the section of this manual that provides an
-:ref:`overview of shard keys <sharding-shard-key>` as well as the
-section that explores the :ref:`features of good shard keys in-depth
+MongoDB uses "range based sharding," you must specify a :term:`shard
+key` that MongoDB can use to distribute your documents among the
+shards. See the section of this manual that provides an :ref:`overview
+of shard keys <sharding-shard-key>` as well as the section that
+explores the :ref:`features of good shard keys in-depth
 <sharding-shard-key>`.
 
 Enable sharding for a collection using the

source/tutorial/remove-shards-from-cluster.txt

@@ -2,6 +2,8 @@
 Remove Shards from an Existing Shard Cluster
 ============================================
 
+.. default-domain:: mongodb
+
 Synopsis
 --------
 
@@ -21,7 +23,7 @@ migrate individual shards as if they were independent replica sets.
 The following list outlines the process for removing shards, from a
 high level:
 
-- Begin moving :term:`chunks` off of the shard.
+- Begin moving :term:`chunks <chunk>` off of the shard.
 
 - Ensure that this shard is not the "primary" shard for any databases
   in the cluster. If it is, move the "primary" status for these