edit: normalizing use of shard cluster across documentation

Author: Sam Kleinman

meta.style-guide.rst

@@ -260,6 +260,15 @@ process, or server instance itself. These are "processes" or
 structure that holds collections and refers to a group of files on
 disk.)
 
+Distributed System Terms
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+- Refer to partitioned systems as "shard clusters," over other
+  variants. (e.g. sharded clusters, or sharded systems.)
+
+- Refer configurations that run with replication as "replica sets" (or
+  "master/slave deployments") rather than "clusters" or other variants.
+
 Data Structures
 ~~~~~~~~~~~~~~~
 

source/administration/backups.txt

@@ -680,7 +680,7 @@ from that instance. When you unlock the database, the slave will catch
 :term:`master` or :term:`primary` node. You may also chose to deploy a
 dedicated :term:`hidden member` for backup purposes.
 
-If you have a sharded cluster where each shard is itself a replica
+If you have a shard cluster where each shard is itself a replica
 set, you can use this method to create a backup of the entire cluster
 without disrupting the operation of the node. In these situations you
 should still turn off the balancer when you create backups.

source/administration/indexes.txt

@@ -266,8 +266,8 @@ building process blocks all replication and read operations on the
 secondaries while they build the index.
 
 Secondaries will begin building indexes *after* the
-:term:`primary` finishes building the index. In :term:`sharded clusters
-<shard cluster>`, the :program:`mongos` will send :func:`ensureIndex()
+:term:`primary` finishes building the index. In :term:`shard clusters`,
+the :program:`mongos` will send :func:`ensureIndex()
 <db.collection.ensureIndex()>` to the primary members of the replica
 set for each shard, which then replicate to the secondaries after the
 primary finishes building the index.

source/core/sharding-internals.txt

@@ -21,7 +21,7 @@ Shard Keys
 ----------
 
 Shard keys are the field in a collection that MongoDB uses to
-distribute :term:`documents <document>` within a sharded cluster. See the
+distribute :term:`documents <document>` within a shard cluster. See the
 :ref:`overview of shard keys <sharding-shard-key>` for an
 introduction to these topics.
 
@@ -169,7 +169,7 @@ compound shard key. The data may become more splitable with a
 compound shard key.
 
 .. see:: ":ref:`sharding-mongos`" for more information on query
-   operations in the context of sharded clusters.
+   operations in the context of shard clusters.
 
 .. [#shard-key-index] In many ways, you can think of the shard key a
    cluster-wide unique index. However, be aware that sharded systems

source/core/sharding.txt

@@ -60,7 +60,7 @@ MongoDB has the following features:
 
    Transparent Query Routing
       Sharding is completely transparent to the application layer,
-      because all connections to a sharded cluster go through
+      because all connections to a shard cluster go through
       :program:`mongos`. Sharding in MongoDB requires some
       :ref:`basic initial configuration <sharding-procedure-setup>`,
       but ongoing function is entirely transparent to the application.
@@ -167,7 +167,7 @@ A :term:`shard cluster` has the following components:
 
      MongoDB enables data :term:`partitioning <partition>`
      (i.e. sharding) on a *per collection* basis. You *must* access
-     all data in a sharded cluster via the :program:`mongos`
+     all data in a shard cluster via the :program:`mongos`
      instances.
 
 - One or more :program:`mongos` instances.

source/faq/developers.txt

@@ -278,7 +278,7 @@ occur simultaneously.
 
 In standalone and :term:`replica sets <replica set>` the lock's scope
 applies to a single :program:`mongod` instance or :term:`primary`
-instance. In a sharded cluster, locks apply to each individual shard,
+instance. In a shard cluster, locks apply to each individual shard,
 not to the whole cluster.
 
 A more granular approach to locking will appear in MongoDB v2.2. For

source/reference/commands.txt

@@ -166,14 +166,14 @@ Sharding
    .. warning::
 
       There's no easy way to disable sharding once you've enabled it. In addition,
-      shard keys are immutable. If you must revert a sharded cluster to a single
+      shard keys are immutable. If you must revert a shard clustero to a single
       node or replica set, you'll have to make a single backup of the entire cluster
       and then restore the backup to the standalone :program:`mongod`.
 
 .. dbcommand:: shardingState
 
    The :dbcommand:`shardingState` command returns ``true`` if the
-   :program:`mongod` instance is a member of a sharded cluster. Run the
+   :program:`mongod` instance is a member of a shard cluster. Run the
    command using the following syntax:
 
    .. code-block:: javascript
@@ -213,7 +213,7 @@ Sharding
    databases remain on the shard. Use :dbcommand:`printShardingStatus`
    to list the databases that you must move from the shard.
 
-   Each database in a sharded cluster has a primary shard. If the
+   Each database in a shard cluster has a primary shard. If the
    shard you want to remove is also the primary of one the cluster's
    databases, then you must manually move the database to a new
    shard. This can be only after the shard is empty. See the
@@ -2551,7 +2551,7 @@ Internal Use
 
    :dbcommand:`writeBacksQueued` is an internal command that returns true if
    there are operations in the write back queue for the given :program:`mongos`.
-   This command applies to sharded clusters only.
+   This command applies to shard clusters only.
 
    .. slave-ok, admin-only
 

source/reference/javascript.txt

@@ -1507,8 +1507,8 @@ that you may use with collection objects.
 .. function:: getShardVersion()
 
    This method returns information regarding the state of data in a
-   sharded cluster that is useful when diagnosing underlying issues
-   with a :term:`shard cluster`.
+   :term:`shard cluster` that is useful when diagnosing underlying issues
+   with a shard cluster.
 
    For internal and diagnostic use only.
 

source/release-notes/2.2.txt

@@ -31,7 +31,7 @@ Read through all release notes before upgrading, and ensure that no
 changes will affect your deployment.
 
 2.2 processes can inter-operate with 2.0 and 1.8 tools and processes
-in replica sets and sharded clusters, if you are not running with
+in replica sets and shard clusters, if you are not running with
 authentication. As a result, you can safely upgrade the
 :program:`mongod` and :program:`mongos` components of your deployment
 in any order.

source/sharding.txt

@@ -47,7 +47,7 @@ Tutorials
 ---------
 
 The following tutorials outline basic administrative process for
-deploying and managing sharded clusters:
+deploying and managing shard clusters:
 
 .. toctree::
    :maxdepth: 1

source/tutorial/convert-replica-set-to-replicated-shard-cluster.txt

@@ -30,15 +30,15 @@ In brief, the process is as follows:
 
 3. Create a second replica set with three new :program:`mongod` processes.
 
-4. Add the second replica set to the sharded cluster.
+4. Add the second replica set to the shard cluster.
 
 5. Enable sharding on the desired collection or collections.
 
 Process
 -------
 
 Install MongoDB according to a ":ref:`MongoDB Installation Tutorial
-<tutorials-installation>`". 
+<tutorials-installation>`".
 
    .. .. note::
 
@@ -146,8 +146,8 @@ set and then insert test data.
    :program:`mongo` shell may take several minutes depending on your
    system.
 
-.. _convert-replica-set-to-shard-cluster-deploy-sharding-infrastructure:   
-   
+.. _convert-replica-set-to-shard-cluster-deploy-sharding-infrastructure:
+
 Deploy Sharding Infrastructure
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -477,4 +477,4 @@ demonstrate that :term:`chunks <chunk>` are migrating from
 ``firstset`` to ``secondset``.
 
 When this procedure is complete, you will have converted a replica set
-into a sharded cluster where each shard is itself a replica set.
+into a shard cluster where each shard is itself a replica set.

source/tutorial/deploy-shard-cluster.txt

@@ -8,18 +8,18 @@ Synopsis
 --------
 
 This document outlines the full procedure for deploying a
-:term:`sharded cluster <shard cluster>` in MongoDB. Use the
+:term:`shard cluster` in MongoDB. Use the
 ":doc:`/tutorial/convert-replica-set-to-replicated-shard-cluster`"
 procedure if you have an existing replica set. If you have a
 standalone :program:`mongod` instance you can use this tutorial to
-deploy a sharded cluster.
+deploy a shard cluster.
 
 Requirements
 ------------
 
 See the ":ref:`Requirements for Shard Clusters
 <sharding-requirements>`" section for more information about potential
-requirements for sharded cluster.
+requirements for shard cluster.
 
 .. warning:: Sharding and "localhost" Addresses