minor whitespace corrections

Author: Sam Kleinman

source/administration/sharding-architectures.txt

@@ -90,7 +90,7 @@ instance or replica set (i.e. a :term:`shard`.)
    ensure that all queries and operations use the :term:`mongos`
    router to access the data cluster. Use the :program:`mongos` even
    for operations that do not impact the sharded data.
- 
+
 Every database has a "primary" [#overloaded-primary-term]_ shard that
 holds all un-sharded collections in that database. All collections
 that *are not* sharded reside on the primary for their database. Use

source/administration/sharding.txt

@@ -8,7 +8,7 @@ Shard Cluster Administration
 .. default-domain:: mongodb
 
 This document provides a collection of basic operations and procedures
-for administering :term:`shard clusters <shard cluster>`. 
+for administering :term:`shard clusters <shard cluster>`.
 
 For a full introduction to sharding in MongoDB see
 ":doc:`/core/sharding`," and for a complete overview of all sharding
@@ -77,7 +77,7 @@ more detail or use the following procedure as a quick starting point:
 
    Run the following commands while connected to a :program:`mongos` to
    initialize the cluster.
- 
+
    First, you need to tell the cluster where to find the individual
    shards. You can do this using the :dbcommand:`addShard` command.
 
@@ -113,13 +113,13 @@ more detail or use the following procedure as a quick starting point:
       If you do not specify a shard name, then MongoDB will assign a
       name upon creation.
 
-   .. note:: 
+   .. note::
 
       .. versionchanged:: 2.0.3
 
       Before version 2.0.3, you must specify the shard in the following
-      form: 
-      
+      form:
+
       .. code-block:: sh
 
          replicaSetName/<seed1>,<seed2>,<seed3>
@@ -192,7 +192,7 @@ more detail or use the following procedure as a quick starting point:
    The choice of shard key is incredibly important: it affects
    everything about the cluster from the efficiency of your queries to
    the distribution of data. Furthermore, you cannot change a
-   collection's shard key once it has been set. 
+   collection's shard key once it has been set.
 
    See the ":ref:`Shard Key Overview <sharding-shard-key>`" and the
    more in depth documentation of ":ref:`Shard Key Qualities
@@ -250,7 +250,7 @@ procedure:
       .. code-block:: javascript
 
          db.runCommand( { addShard: mongodb0.example.net, name: "mongodb0" } )
-	 
+
       Or:
 
       .. code-block:: javascript
@@ -423,7 +423,7 @@ You may want to split chunks manually if:
 - you have a large amount of data in your cluster that is *not* split,
   as is the case after creating a shard cluster with existing data.
 
-- you expect to add a large amount of data that would 
+- you expect to add a large amount of data that would
   initially reside in a single chunk or shard.
 
 .. example::
@@ -622,12 +622,12 @@ When this command returns, you will see output like the following:
 
 .. code-block:: javascript
 
-   {   "_id" : "balancer", 
-   "process" : "guaruja:1292810611:1804289383", 
-     "state" : 2, 
-        "ts" : ObjectId("4d0f872630c42d1978be8a2e"), 
-      "when" : "Mon Dec 20 2010 11:41:10 GMT-0500 (EST)", 
-       "who" : "guaruja:1292810611:1804289383:Balancer:846930886", 
+   {   "_id" : "balancer",
+   "process" : "guaruja:1292810611:1804289383",
+     "state" : 2,
+        "ts" : ObjectId("4d0f872630c42d1978be8a2e"),
+      "when" : "Mon Dec 20 2010 11:41:10 GMT-0500 (EST)",
+       "who" : "guaruja:1292810611:1804289383:Balancer:846930886",
        "why" : "doing balance round" }
 
 
@@ -720,8 +720,8 @@ all migration, use the following procedure:
 
       sh.setBalancerState(true)
 
-.. note:: 
-   
+.. note::
+
    If a balancing round is in progress, the system will complete the
    current round before the balancer is officially disabled.  After
    disabling, you can use the :func:`sh.getBalancerState()` shell
@@ -790,7 +790,7 @@ three config servers.
    existing config server to the two machines that will provide the
    additional config servers. These commands, issued on the system
    with the existing config database, ``mongo-config0.example.net`` may
-   look like the following: 
+   look like the following:
 
    .. code-block:: sh
 
@@ -858,7 +858,7 @@ possible, avoid changing the hostname so that you can use the
 
 #. Shut down the config server that you are moving.
 
-   This will render all config data for your cluster "read only:" 
+   This will render all config data for your cluster "read only:"
 
 .. TODO - make link to config servers page
 

source/core/sharding-internals.txt

@@ -154,7 +154,7 @@ provides better performance. Even if you query values of the shard
 key reside in different chunks, the :program:`mongos` will route
 queries directly to specific shards.
 
-To select a shard key for a collection: 
+To select a shard key for a collection:
 
 - determine which fields are included most frequently in queries for a
   given application
@@ -216,7 +216,7 @@ Furethermore:
 
 - If your shard key distributes data required for every operation
   throughout the cluster, then the failure of the entire shard will
-  render the entire cluster unavailable. 
+  render the entire cluster unavailable.
 
 In essence, this concern for reliably simply underscores the
 importance of choosing a shard key that isolates query operations to a
@@ -240,10 +240,10 @@ are three options:
    write operations and query isolation.
 
 #. Determine that the impact of using a less than ideal shard key,
-   is insignificant in your use case given: 
+   is insignificant in your use case given:
 
    - limited write volume,
-   - expected data size, or 
+   - expected data size, or
    - query patterns and demands.
 
 From a decision making stand point, begin by finding the field
@@ -323,7 +323,7 @@ Chunk size is arbitrary and must account for the following:
 
 #. Small chunks lead to a more even distribution of data at the
    expense of more frequent migrations, which creates expense at the
-   query routing (:program:`mongos`) layer.  Or
+   query routing (:program:`mongos`) layer.
 
 #. Large chunks lead to fewer migrations, which is more efficient both
    from the networking perspective *and* in terms internal overhead at