From 02954796f28de6441af703b35847ac4896bda676 Mon Sep 17 00:00:00 2001 From: Bob Grabar Date: Fri, 12 Oct 2012 16:34:11 -0400 Subject: [PATCH] DOCS-303 shard cluster to sharded cluster --- draft/core/write-operations.txt | 2 +- ...ng-documents-into-a-sharded-collection.txt | 2 +- draft/use-cases/gaming-user-state.txt | 2 +- meta.style-guide.rst | 6 +++--- source/administration/backups.txt | 4 ++-- source/administration/monitoring.txt | 4 ++-- source/administration/replica-sets.txt | 2 +- .../administration/sharding-architectures.txt | 4 ++-- source/administration/sharding.txt | 16 +++++++-------- source/applications/replication.txt | 10 +++++----- source/core/sharding-internals.txt | 6 +++--- source/core/sharding.txt | 20 +++++++++---------- source/faq/developers.txt | 2 +- source/faq/sharding.txt | 6 +++--- .../includes/note-config-server-startup.rst | 2 +- source/includes/note-conn-pool-stats.rst | 2 +- source/reference/command/fsync.txt | 4 ++-- source/reference/command/group.txt | 2 +- .../command/mapreduce.shardedfinish.txt | 2 +- source/reference/command/movePrimary.txt | 2 +- source/reference/command/shardingState.txt | 2 +- source/reference/configuration-options.txt | 2 +- source/reference/glossary.txt | 10 +++++----- .../reference/method/db.collection.group.txt | 2 +- source/reference/method/getShardVersion.txt | 2 +- source/reference/mongod.txt | 2 +- source/reference/mongodump.txt | 2 +- source/reference/mongos.txt | 2 +- source/reference/mongostat.txt | 2 +- source/release-notes/2.2.txt | 2 +- source/sharding.txt | 2 +- source/tutorial/deploy-shard-cluster.txt | 4 ++-- 32 files changed, 67 insertions(+), 67 deletions(-) diff --git a/draft/core/write-operations.txt b/draft/core/write-operations.txt index 4d491cdc132..a1713aff0fa 100644 --- a/draft/core/write-operations.txt +++ b/draft/core/write-operations.txt @@ -46,4 +46,4 @@ Architecture .. ordered list: - atomicity -- replica sets / shard clusters +- replica sets / sharded clusters diff --git a/draft/tutorial/inserting-documents-into-a-sharded-collection.txt b/draft/tutorial/inserting-documents-into-a-sharded-collection.txt index d620103f068..22dde465996 100644 --- a/draft/tutorial/inserting-documents-into-a-sharded-collection.txt +++ b/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 ` 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. diff --git a/draft/use-cases/gaming-user-state.txt b/draft/use-cases/gaming-user-state.txt index c01150e832e..8b2b5bc7a85 100644 --- a/draft/use-cases/gaming-user-state.txt +++ b/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. diff --git a/meta.style-guide.rst b/meta.style-guide.rst index fc89a2454e0..f882e7615fe 100644 --- a/meta.style-guide.rst +++ b/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 diff --git a/source/administration/backups.txt b/source/administration/backups.txt index 6ec21ea430f..11d0043187e 100644 --- a/source/administration/backups.txt +++ b/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 ` and :term:`sharded clusters ` +:term:`Replica sets ` and :term:`sharded clusters` require special considerations. Don't miss the :ref:`backup considerations for sharded clusters and replica sets `. @@ -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 ` 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 ` before taking the backup. diff --git a/source/administration/monitoring.txt b/source/administration/monitoring.txt index e44dff51a87..5c7d5badb3e 100644 --- a/source/administration/monitoring.txt +++ b/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. diff --git a/source/administration/replica-sets.txt b/source/administration/replica-sets.txt index caf91f46ca4..c1ef227476a 100644 --- a/source/administration/replica-sets.txt +++ b/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 ` 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. diff --git a/source/administration/sharding-architectures.txt b/source/administration/sharding-architectures.txt index 43ef7279bf5..6ae4c81f288 100644 --- a/source/administration/sharding-architectures.txt +++ b/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 ` deployments. +cluster` deployments. .. seealso:: The :doc:`/administration/sharding` document, the ":ref:`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:: diff --git a/source/administration/sharding.txt b/source/administration/sharding.txt index 8da08131900..4c0db0124c0 100644 --- a/source/administration/sharding.txt +++ b/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 ` in :term:`sharded clusters `. 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 `. diff --git a/source/applications/replication.txt b/source/applications/replication.txt index 38b148bd5b8..24e0dfe45ac 100644 --- a/source/applications/replication.txt +++ b/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 ` where the +.. [#sharded-clusters] :term:`Sharded clusters ` 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 `, 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 diff --git a/source/core/sharding-internals.txt b/source/core/sharding-internals.txt index ca86fe18c5b..8bf8a4805c9 100644 --- a/source/core/sharding-internals.txt +++ b/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 ` within a shard cluster. See the +distribute :term:`documents ` within a sharded cluster. See the :ref:`overview of shard keys ` 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 shard clusters. + operations in the context of sharded 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 @@ -402,7 +402,7 @@ than two.* The specification of the balancing window is relative to the local time zone of all individual :program:`mongos` instances in the - shard cluster. + sharded cluster. .. index:: sharding; chunk size .. _sharding-chunk-size: diff --git a/source/core/sharding.txt b/source/core/sharding.txt index 8154017d043..b2b027cb782 100644 --- a/source/core/sharding.txt +++ b/source/core/sharding.txt @@ -114,7 +114,7 @@ You should consider deploying a :term:`sharded cluster`, if: If these attributes are not present in your system, sharding will only add additional complexity to your system without providing much benefit. When designing your data model, if you will eventually need a -shard cluster, consider which collections you will want to shard and +sharded cluster, consider which collections you will want to shard and the corresponding shard keys. .. _sharding-capacity-planning: @@ -169,7 +169,7 @@ A :term:`sharded cluster` has the following components: MongoDB enables data :term:`partitioning `, or sharding, on a *per collection* basis. You *must* access all data in a sharded cluster via the :program:`mongos` instances as below. - If you connect directly to a :program:`mongod` in a shard cluster + If you connect directly to a :program:`mongod` in a sharded cluster you will see its fraction of cluster's data. The data on any given shard may be somewhat random: MongoDB provides no grantee that any two contiguous chunks will reside on a single shard. @@ -304,7 +304,7 @@ within a :term:`sharded cluster`. Without a config database, the operations within the cluster. Config servers *do not* run as replica sets. Instead, a :term:`cluster -` operates with a group of *three* config servers that use a +` operates with a group of *three* config servers that use a two-phase commit process that ensures immediate consistency and reliability. @@ -330,7 +330,7 @@ database. MongoDB only writes data to the config server to: - migrate a chunk between shards. Additionally, all config servers must be available on initial setup -of a shard cluster, each :program:`mongos` instance must be able +of a sharded cluster, each :program:`mongos` instance must be able to write to the ``config.version`` collection. If one or two configuration instances become unavailable, the @@ -354,7 +354,7 @@ 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 of activity is relatively low, and 100% -up time is not required for a functioning shard cluster. As a result, +up time is not required for a functioning sharded cluster. As a result, backing up the config servers is not difficult. Backups of config servers are critical as clusters become totally inoperable when you lose all configuration instances and data. Precautions to ensure @@ -362,7 +362,7 @@ that the config servers remain available and intact are critical. .. note:: - Configuration servers store metadata for a single shard cluster. + Configuration servers store metadata for a single sharded cluster. You must have a separate configuration server or servers for each cluster you administer. @@ -561,18 +561,18 @@ Security enforce read-only limitations. .. versionchanged:: 2.0 - Shard clusters support authentication. Previously, in version + Sharded clusters support authentication. Previously, in version 1.8, sharded clusters will not support authentication and access control. You must run your sharded systems in trusted environments. -To control access to a shard cluster, you must set the -:setting:`keyFile` option on all components of the shard cluster. Use +To control access to a sharded cluster, you must set the +:setting:`keyFile` option on all components of the sharded cluster. Use the :option:`--keyFile ` run-time option or the :setting:`keyFile` configuration option for all :program:`mongos`, configuration instances, and shard :program:`mongod` instances. -There are two classes of security credentials in a shard cluster: +There are two classes of security credentials in a sharded cluster: credentials for "admin" users (i.e. for the :term:`admin database`) and credentials for all other databases. These credentials reside in different locations within the cluster and have different roles: diff --git a/source/faq/developers.txt b/source/faq/developers.txt index 2fd33d76d3b..35db80d4345 100644 --- a/source/faq/developers.txt +++ b/source/faq/developers.txt @@ -280,7 +280,7 @@ occur simultaneously. In standalone and :term:`replica sets ` the lock's scope applies to a single :program:`mongod` instance or :term:`primary` -instance. In a shard cluster, locks apply to each individual shard, +instance. In a sharded 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 diff --git a/source/faq/sharding.txt b/source/faq/sharding.txt index 991a67c684f..8f5cd1689c1 100644 --- a/source/faq/sharding.txt +++ b/source/faq/sharding.txt @@ -81,7 +81,7 @@ How does MongoDB distribute queries among shards? The exact method for distributing queries to :term:`shards ` in a :term:`cluster ` depends on the nature of the query and the configuration of -the shard cluster. Consider a sharded collection, using the +the sharded cluster. Consider a sharded collection, using the :term:`shard key` ``user_id``, that has ``last_login`` and ``email`` attributes: @@ -274,7 +274,7 @@ Can shard keys be randomly generated? :term:`Shard keys ` can be random. Random keys ensure optimal distribution of data across the cluster. -:term:`Shard clusters `, attempt to route queries to +:term:`Sharded clusters `, attempt to route queries to *specific* shards when queries include the shard key as a parameter, because these directed queries are more efficient. In many cases, random keys can make it difficult to direct queries to specific @@ -291,7 +291,7 @@ the shard key. However, documents that have the shard key *must* reside in the same *chunk* and therefore on the same server. If your sharded data set has too many documents with the exact same shard key you will not be able -to distribute *those* documents across your shard cluster. +to distribute *those* documents across your sharded cluster. .. STUB link to shard key granularity. diff --git a/source/includes/note-config-server-startup.rst b/source/includes/note-config-server-startup.rst index 1f975086bb5..a1d3c2d81fa 100644 --- a/source/includes/note-config-server-startup.rst +++ b/source/includes/note-config-server-startup.rst @@ -1,4 +1,4 @@ .. note:: All config servers must be running and available when you first initiate - a :term:`shard cluster`. + a :term:`sharded cluster`. diff --git a/source/includes/note-conn-pool-stats.rst b/source/includes/note-conn-pool-stats.rst index 19a8a7f5e2f..d66ab98c38f 100644 --- a/source/includes/note-conn-pool-stats.rst +++ b/source/includes/note-conn-pool-stats.rst @@ -2,4 +2,4 @@ :dbcommand:`connPoolStats` only returns meaningful results for :program:`mongos` instances and for :program:`mongod` instances - in shard clusters. + in sharded clusters. diff --git a/source/reference/command/fsync.txt b/source/reference/command/fsync.txt index 6c13b6c2d15..f07a492ddfa 100644 --- a/source/reference/command/fsync.txt +++ b/source/reference/command/fsync.txt @@ -89,8 +89,8 @@ fsync .. note:: :dbcommand:`fsync` lock is only possible on individual shards of - a shard cluster, not on the entire shard cluster. To backup an - entire shard cluster, please read :ref:`considerations for + a sharded cluster, not on the entire sharded cluster. To backup an + entire sharded cluster, please read :ref:`considerations for backing up sharded clusters `. If your :program:`mongod` has :term:`journaling ` diff --git a/source/reference/command/group.txt b/source/reference/command/group.txt index 186acf12646..8027cf2de1f 100644 --- a/source/reference/command/group.txt +++ b/source/reference/command/group.txt @@ -82,7 +82,7 @@ group .. warning:: :method:`group()` does not work in :term:`shard environments - `. Use the :term:`aggregation framework` or + `. Use the :term:`aggregation framework` or :term:`map-reduce` (i.e. :command:`mapReduce` in :term:`sharded environments `. diff --git a/source/reference/command/mapreduce.shardedfinish.txt b/source/reference/command/mapreduce.shardedfinish.txt index 4b58a4f3431..f979cf1c9c5 100644 --- a/source/reference/command/mapreduce.shardedfinish.txt +++ b/source/reference/command/mapreduce.shardedfinish.txt @@ -7,7 +7,7 @@ mapreduce.shardedfinish (internal) .. dbcommand:: mapreduce.shardedfinish Provides internal functionality to support :term:`map-reduce` in - :term:`sharded ` environments. + :term:`sharded ` environments. .. seealso:: ":dbcommand:`mapReduce`" diff --git a/source/reference/command/movePrimary.txt b/source/reference/command/movePrimary.txt index 264a21e4952..e8c3c3c7822 100644 --- a/source/reference/command/movePrimary.txt +++ b/source/reference/command/movePrimary.txt @@ -11,7 +11,7 @@ movePrimary un-sharded collections in the database. :dbcommand:`movePrimary` is an administrative command that is only available for :program:`mongos` instances. Only use :dbcommand:`movePrimary` when - removing a shard from a shard cluster. + removing a shard from a sharded cluster. :dbcommand:`movePrimary` changes the primary shard for this database in the cluster metadata, and migrates all un-sharded diff --git a/source/reference/command/shardingState.txt b/source/reference/command/shardingState.txt index a437542ce83..1c378c79a57 100644 --- a/source/reference/command/shardingState.txt +++ b/source/reference/command/shardingState.txt @@ -7,7 +7,7 @@ shardingState .. dbcommand:: shardingState The :dbcommand:`shardingState` command returns ``true`` if the - :program:`mongod` instance is a member of a shard cluster. Run the + :program:`mongod` instance is a member of a sharded cluster. Run the command using the following syntax: .. code-block:: javascript diff --git a/source/reference/configuration-options.txt b/source/reference/configuration-options.txt index 76dce921de1..b8f96b0d4e6 100644 --- a/source/reference/configuration-options.txt +++ b/source/reference/configuration-options.txt @@ -790,7 +790,7 @@ Sharding Cluster Options the cluster for the first time. If you modify the run-time option later, the new value will have no effect. See the ":ref:`sharding-balancing-modify-chunk-size`" procedure if you - need to change the chunk size on an existing shard cluster. + need to change the chunk size on an existing sharded cluster. .. setting:: localThreshold diff --git a/source/reference/glossary.txt b/source/reference/glossary.txt index 0531b974e5b..5a06d6a44ce 100644 --- a/source/reference/glossary.txt +++ b/source/reference/glossary.txt @@ -103,7 +103,7 @@ Glossary :doc:`/replication`. and :doc:`/core/replication`. shard - A single replica set that stores some portion of a shard cluster's + A single replica set that stores some portion of a sharded cluster's total data set. See :term:`sharding`. .. seealso:: The documents in the :doc:`/sharding` section of manual. @@ -115,15 +115,15 @@ Glossary .. seealso:: The documents in the :doc:`/sharding` section of manual. - shard cluster - The set of nodes comprising a :term:`sharded ` MongoDB deployment. A shard cluster + sharded cluster + The set of nodes comprising a :term:`sharded ` MongoDB deployment. A sharded cluster consists of three config processes, one or more replica sets, and one or more :program:`mongos` routing processes. .. seealso:: The documents in the :doc:`/sharding` section of manual. sharded cluster - The set of nodes comprising a :term:`sharded ` MongoDB deployment. A shard cluster + The set of nodes comprising a :term:`sharded ` MongoDB deployment. A sharded cluster consists of three config processes, one or more replica sets, and one or more :program:`mongos` routing processes. @@ -371,7 +371,7 @@ Glossary An internal MongoDB process that runs in the context of a :term:`sharded cluster` and manages the splitting and migration of :term:`chunks `. Administrators must disable - the balancer for all maintenance operations on a shard cluster. + the balancer for all maintenance operations on a sharded cluster. fsync A system call that flushes all dirty, in-memory pages to disk. MongoDB diff --git a/source/reference/method/db.collection.group.txt b/source/reference/method/db.collection.group.txt index 7cd8bc2783c..3a3c10545ab 100644 --- a/source/reference/method/db.collection.group.txt +++ b/source/reference/method/db.collection.group.txt @@ -46,7 +46,7 @@ db.collection.group() .. warning:: :method:`db.collection.group()` does not work in :term:`shard environments - `. Use the :term:`aggregation framework` or + `. Use the :term:`aggregation framework` or :term:`map-reduce` in :term:`sharded environments `. .. note:: diff --git a/source/reference/method/getShardVersion.txt b/source/reference/method/getShardVersion.txt index acbb1a0fae0..9d67505fc1a 100644 --- a/source/reference/method/getShardVersion.txt +++ b/source/reference/method/getShardVersion.txt @@ -8,6 +8,6 @@ getShardVersion() This method returns information regarding the state of data in a :term:`sharded cluster` that is useful when diagnosing underlying issues - with a shard cluster. + with a sharded cluster. For internal and diagnostic use only. diff --git a/source/reference/mongod.txt b/source/reference/mongod.txt index 300dd28cf75..99f41df4b24 100644 --- a/source/reference/mongod.txt +++ b/source/reference/mongod.txt @@ -564,7 +564,7 @@ Sharding Cluster Options .. option:: --configsvr Declares that this :program:`mongod` instance serves as the - :term:`config database` of a shard cluster. The default port for + :term:`config database` of a sharded cluster. The default port for :program:`mongod` with this option is ``27019`` and :program:`mongod` writes all data files to the ``/configdb`` sub-directory of the :option:`--dbpath` directory. diff --git a/source/reference/mongodump.txt b/source/reference/mongodump.txt index d4f8bf1b2b4..ed3e790c1ae 100644 --- a/source/reference/mongodump.txt +++ b/source/reference/mongodump.txt @@ -160,7 +160,7 @@ Options :option:`--oplog` has no effect when running :program:`mongodump` against a :program:`mongos` instance to dump the entire contents of - a shard cluster. However, you can use :option:`--oplog` to dump + a sharded cluster. However, you can use :option:`--oplog` to dump individual shards. .. note:: diff --git a/source/reference/mongos.txt b/source/reference/mongos.txt index a50cce1f746..e56534de135 100644 --- a/source/reference/mongos.txt +++ b/source/reference/mongos.txt @@ -213,7 +213,7 @@ Options cluster for the first time. If you modify the run-time option later, the new value will have no effect. See the ":ref:`sharding-balancing-modify-chunk-size`" procedure if you - need to change the chunk size on an existing shard cluster. + need to change the chunk size on an existing sharded cluster. .. option:: --ipv6 diff --git a/source/reference/mongostat.txt b/source/reference/mongostat.txt index 4eb0c529ea2..a3fe9850d2b 100644 --- a/source/reference/mongostat.txt +++ b/source/reference/mongostat.txt @@ -121,7 +121,7 @@ Options member>` of the replica set. When connected to a :program:`mongos`, :program:`mongostat` will return data from all :term:`shards ` in the cluster. If a replica set provides a shard in the - shard cluster, :program:`mongostat` will report on non-hidden + sharded cluster, :program:`mongostat` will report on non-hidden members of that replica set. The :option:`mongostat --host` option is not required but diff --git a/source/release-notes/2.2.txt b/source/release-notes/2.2.txt index 2e5b55ff7f7..edc1dc3eb84 100644 --- a/source/release-notes/2.2.txt +++ b/source/release-notes/2.2.txt @@ -269,7 +269,7 @@ If your cluster runs with authentication: - In sharded environments, to ensure that your cluster remains available during the upgrade - process you **must** use the :ref:`upgrade procedure for shard clusters + process you **must** use the :ref:`upgrade procedure for sharded clusters <2.2-upgrade-shard-cluster>`. .. _2.2-findandmodify-returns-null: diff --git a/source/sharding.txt b/source/sharding.txt index 57b04a53cde..cc6f7c0d0da 100644 --- a/source/sharding.txt +++ b/source/sharding.txt @@ -14,7 +14,7 @@ This page lists the documents, tutorials, and reference pages that describe sharding. For an overview, see :doc:`/core/sharding`. To configure, maintain, and -troubleshoot shard clusters, see :doc:`/administration/sharding`. For +troubleshoot sharded clusters, see :doc:`/administration/sharding`. For deployment architectures, see :doc:`/administration/sharding-architectures`. For details on the internal operations of sharding, see :doc:`/core/sharding-internals`. diff --git a/source/tutorial/deploy-shard-cluster.txt b/source/tutorial/deploy-shard-cluster.txt index 410d891f522..b3a7d614997 100644 --- a/source/tutorial/deploy-shard-cluster.txt +++ b/source/tutorial/deploy-shard-cluster.txt @@ -4,7 +4,7 @@ Deploy a Sharded Cluster .. default-domain:: mongodb -This document describes how to deploy a :term:`sharded cluster ` for a +This document describes how to deploy a :term:`sharded cluster` for a standalone :program:`mongod` instance. To deploy a cluster for an existing replica set, see :doc:`/tutorial/convert-replica-set-to-replicated-shard-cluster`. @@ -12,7 +12,7 @@ existing replica set, see Procedure --------- -Before deploying a shard cluster, see the requirements listed in +Before deploying a sharded cluster, see the requirements listed in :ref:`Requirements for Sharded Clusters `. .. include:: /includes/warning-sharding-hostnames.rst