DOCS-220 | DOCS-226 edits + DOCS-226 edits

Author: Andrew Leung

source/administration/sharding-architectures.txt

@@ -16,7 +16,7 @@ cluster` deployments.
    and the ":ref:`Sharding Tutorials <sharding-tutorials>`" for more
    information on deploying and maintaining a :term:`shard cluster`.
 
-Deploying A Test Cluster
+Deploying a Test Cluster
 ------------------------
 
 .. warning:: Use this architecture for testing and development only.
@@ -38,6 +38,8 @@ When deploying a shard cluster to production, you must ensure that the data
 is redundant and that your individual nodes are highly available. To that end,
 a production-level shard cluster should have the following:
 
+.. TODO - 'highly available' ? would 'highly accessible' make more sense? 
+
 - 3 :ref:`config servers <sharding-config-server>`, each residing on a separate node.
 
 - For each shard, a three member :term:`replica set <replica set>` consisting of:
@@ -86,7 +88,7 @@ instance or replica set (i.e. a :term:`shard`.)
 
 .. note::
 
-   Regardless of the data architecture in your :term:`shard cluster`
+   Regardless of the data architecture of your :term:`shard cluster`,
    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.
@@ -106,6 +108,9 @@ cluster.
    it copies all non-sharded data between shards, during which
    that data will be unavailable for other operations.
 
+.. TODO - isn't this expensive because data is moving from old
+.. primary to new primary?
+
 When you deploy a new :term:`shard cluster`, the "first shard" becomes
 the primary for all databases before enabling sharding. Databases
 created subsequently, may reside on any shard in the cluster.