DOCS-303 shard cluster to sharded cluster

Author: Bob Grabar

draft/core/write-operations.txt

@@ -46,4 +46,4 @@ Architecture
 .. ordered list:
 
 - atomicity
-- replica sets / shard clusters
+- replica sets / sharded clusters

draft/tutorial/inserting-documents-into-a-sharded-collection.txt

@@ -81,7 +81,7 @@ in the :ref:`sharding-pre-splitting` section below.
 Uneven distribution occurs in the following cases:
 
 - You insert a large volume of data that is not evenly distributed. Even
-  if the :term:`sharded cluster <shard cluster>` contains existing
+  if the :term:`sharded cluster` contains existing
   documents balanced over multiple chunks, the inserted data might
   include values that write disproportionately to a small number of
   chunks.

draft/use-cases/gaming-user-state.txt

@@ -570,7 +570,7 @@ Sharding
 --------
 
 If your system needs to scale beyond a single MongoDB instance node,
-you will want to use a :term:`shard cluster`, which takes advantage of
+you will want to use a :term:`sharded cluster`, which takes advantage of
 MongoDB's :term:`sharding` functionality.
 
 .. see:: ":doc:`/faq/sharding`" and the ":wiki:`Sharding` wiki page.

meta.style-guide.rst

@@ -157,7 +157,7 @@ Referencing
 
   Type this:
 
-  To deploy a shard cluster for an existing replica set, see
+  To deploy a sharded cluster for an existing replica set, see
   :doc:`/tutorial/convert-replica-set-to-replicated-shard-cluster`.
 
 General Formulations
@@ -277,7 +277,7 @@ disk.)
 Distributed System Terms
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-- Refer to partitioned systems as "shard clusters," over other
+- Refer to partitioned systems as "sharded clusters," over other
   variants. (e.g. sharded clusters, or sharded systems.)
 
 - Refer configurations that run with replication as "replica sets" (or
@@ -317,7 +317,7 @@ Notes on Specific Features
 Other Terms
 ~~~~~~~~~~~
 
-- Use "**shard cluster**," to refer to a collection of ``mongod``
+- Use "**sharded cluster**," to refer to a collection of ``mongod``
   instances that hold a sharded data set. Use the term "**replica
   set**," to refer to a collection of ``mongod`` instances that
   provide a replicated data set. Do not use the word "cluster" to

source/administration/backups.txt

@@ -18,7 +18,7 @@ process is crucial for every production-grade deployment. Take the
 specific features of your deployment, your use patterns, and
 architecture into consideration as you develop your own backup system.
 
-:term:`Replica sets <replica set>` and :term:`sharded clusters <shard cluster>`
+:term:`Replica sets <replica set>` and :term:`sharded clusters`
 require special considerations. Don't miss the :ref:`backup
 considerations for sharded clusters and replica sets
 <backups-with-sharding-and-replication>`.
@@ -595,7 +595,7 @@ binary dump of each database instance using :ref:`binary dump methods
 
 These backups must not only capture the database in a consistent
 state, as described in the aforementioned procedures, but the
-:term:`sharded cluster <shard cluster>` needs to be consistent in itself. Also, disable
+:term:`sharded cluster` needs to be consistent in itself. Also, disable
 the balancer process that equalizes the distribution of data among the
 :term:`shards <shard>` before taking the backup.
 

source/administration/monitoring.txt

@@ -14,7 +14,7 @@ waiting for a crisis or failure.
 This document provides an overview of the available tools and data
 provided by MongoDB as well as introduction to diagnostic strategies,
 and suggestions for monitoring instances in MongoDB's replica sets and
-shard clusters.
+sharded clusters.
 
 .. note::
 
@@ -488,7 +488,7 @@ instances become unavailable. However, clusters remain
 accessible from already-running :program:`mongos` instances.
 
 Because inaccessible configuration servers can have a serious impact
-on the availability of a shard cluster, you should monitor the
+on the availability of a sharded cluster, you should monitor the
 configuration servers to ensure that the cluster remains well
 balanced and that :program:`mongos` instances can restart.
 

source/administration/replica-sets.txt

@@ -171,7 +171,7 @@ other members in the set will not advertise the hidden member in the
 
    .. versionchanged:: 2.0 
 
-   For :term:`sharded clusters <shard cluster>` running with replica sets before 2.0 if
+   For :term:`sharded clusters` running with replica sets before 2.0 if
    you reconfigured a member as hidden, you *had* to restart
    :program:`mongos` to prevent queries from reaching the hidden
    member.

source/administration/sharding-architectures.txt

@@ -9,7 +9,7 @@ Sharded Cluster Architectures
 .. default-domain:: mongodb
 
 This document describes the organization and design of :term:`sharded
-cluster <shard cluster>` deployments.
+cluster` deployments.
 
 .. seealso:: The :doc:`/administration/sharding` document, the
    ":ref:`Sharding Requirements <sharding-requirements>`" section,
@@ -90,7 +90,7 @@ that *are not* sharded reside on the primary for their database. Use
 the :dbcommand:`movePrimary` command to change the primary shard for a
 database. Use the :dbcommand:`printShardingStatus` command or the
 :method:`sh.status()` to see an overview of the cluster, which contains
-information about the chunk and database distribution within the
+information about the :term:`chunk` and database distribution within the
 cluster.
 
 .. warning::

source/administration/sharding.txt

@@ -12,7 +12,7 @@ clusters. For a full introduction to sharding in MongoDB see
 :doc:`/core/sharding`, and for a complete overview of all sharding
 documentation in the MongoDB Manual, see :doc:`/sharding`. The
 :doc:`/administration/sharding-architectures` document provides an
-overview of deployment possibilities to help deploy a shard
+overview of deployment possibilities to help deploy a sharded
 cluster. Finally, the :doc:`/core/sharding-internals` document
 provides a more detailed introduction to sharding when troubleshooting
 issues or understanding your cluster's behavior.
@@ -192,7 +192,7 @@ use the following procedure as a quick starting point:
 Cluster Management
 ------------------
 
-Once you have a running shard cluster, you will need to maintain it.
+Once you have a running sharded cluster, you will need to maintain it.
 This section describes common maintenance procedure, including: how to
 add and remove nodes, how to manually split chunks, and how to disable
 the balancer for backups.
@@ -213,7 +213,7 @@ command:
 Add a Shard to a Cluster
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-To add a shard to an *existing* shard cluster, use the following
+To add a shard to an *existing* sharded cluster, use the following
 procedure:
 
 #. Connect to a :program:`mongos` in the cluster using the
@@ -405,7 +405,7 @@ Chunk Management
 This section describes various operations on :term:`chunks <chunk>` in
 :term:`sharded clusters <sharded cluster>`. MongoDB automates these
 processes; however, in some cases, particularly when you're setting up
-a shard cluster, you may need to create and manipulate chunks
+a sharded cluster, you may need to create and manipulate chunks
 directly.
 
 .. _sharding-procedure-create-split:
@@ -558,7 +558,7 @@ To create and migrate chunks manually, use the following procedure:
 Modify Chunk Size
 ~~~~~~~~~~~~~~~~~
 
-When you initialize a shard cluster, the default chunk size is 64
+When you initialize a sharded cluster, the default chunk size is 64
 megabytes. This default chunk size works well for most deployments. However, if you
 notice that automatic migrations are incurring a level of I/O that
 your hardware cannot handle, you may want to reduce the chunk
@@ -790,7 +790,7 @@ be able to migrate chunks:
    two digit hour and minute values (e.g ``HH:MM``) that describe the
    beginning and end boundaries of the balancing window.
    These times will be evaluated relative to the time zone of each individual
-   :program:`mongos` instance in the shard cluster.
+   :program:`mongos` instance in the sharded cluster.
    For instance, running the following
    will force the balancer to run between 11PM and 6AM local time only:
 
@@ -1109,7 +1109,7 @@ default chunk size is configurable with the :setting:`chunkSize`
 setting, these behaviors help prevent unnecessary chunk migrations,
 which can degrade the performance of your cluster as a whole.
 
-If you have just deployed a shard cluster, make sure that you have
+If you have just deployed a sharded cluster, make sure that you have
 enough data to make sharding effective. If you do not have sufficient
 data to create more than eight 64 megabyte chunks, then all data will
 remain on one shard. Either lower the :ref:`chunk size
@@ -1144,7 +1144,7 @@ to correct this pattern.
 The Cluster does not Balance
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If you have just deployed your shard cluster, you may want to
+If you have just deployed your sharded cluster, you may want to
 consider the :ref:`troubleshooting suggestions for a new cluster where
 data remains on a single shard <sharding-troubleshooting-not-splitting>`.
 

source/applications/replication.txt

@@ -7,10 +7,10 @@ Application Development with Replica Sets
 From the perspective of a client application, whether a MongoDB
 instance is running as a single server (i.e. "standalone") or a :term:`replica set`
 is transparent. However, replica sets
-offer some configuration options for write and read operations. [#shard-clusters]_
+offer some configuration options for write and read operations. [#sharded-clusters]_
 This document describes those options and their implications.
 
-.. [#shard-clusters] :term:`Shard clusters <shard cluster>` where the
+.. [#sharded-clusters] :term:`Sharded clusters <sharded cluster>` where the
    shards are also replica sets provide the same configuration options
    with regards to write and read operations.
 
@@ -529,7 +529,7 @@ Member Selection
 ````````````````
 
 Both clients, by way of their drivers, and :program:`mongos` instances for
-shard clusters send periodic "ping," messages to all member of the
+sharded clusters send periodic "ping," messages to all member of the
 replica set to determine latency from the application to each
 :program:`mongod` instance.
 
@@ -573,10 +573,10 @@ Sharding and ``mongos``
 
 In most :term:`sharded clusters <sharded cluster>`, a :term:`replica set`
 provides each shard where read preferences are also applicable. Read
-operations in a shard cluster, with regard to read preference, are
+operations in a sharded cluster, with regard to read preference, are
 identical to unsharded replica sets.
 
-Unlike simple replica sets, in shard clusters, all interactions with
+Unlike simple replica sets, in sharded clusters, all interactions with
 the shards pass from the clients to the :program:`mongos` instances
 that are actually connected to the set members. :program:`mongos` is
 responsible for the application of the read preferences, which is