DOCS-421 added in _secondaryThrottle parameter description

source/administration/sharding.txt

@@ -566,6 +566,13 @@ This command moves the chunk that includes the shard key value "smith" to the
 :term:`shard` named ``mongodb-shard3.example.net``. The command will
 block until the migration is complete.
 
+.. versionadded:: 2.2
+
+   :dbcommand:`moveChunk` command accepts parameter:
+   ``_secondaryThrottle``, when set to ``true``, MongoDB will ensure
+   :term:`secondary` members have replicated changes before allowing new chunk
+   migrations to occur.
+
 .. note::
 
    To return a list of shards, use the :dbcommand:`listshards`
@@ -691,6 +698,13 @@ be able to migrate chunks:
 
       db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "23:00", stop : "6:00" } } }, true )
 
+To turn off the balancing window:
+
+  .. code-block:: javascript
+
+     use config
+     db.settings.update({ _id : "balancer" }, { $unset : { activeWindow : true })
+
 .. note::
 
    The balancer window must be sufficient to *complete* the migration

source/core/sharding-internals.txt

@@ -374,7 +374,7 @@ chunks. The balancer has the following thresholds:
 Number of Chunks  Migration Threshold
 ----------------  -------------------
 Greater than 80    8
-80-21              4
+21-80              4
 Less than 20       2
 ================  ===================
 
@@ -449,3 +449,50 @@ to the shard when the value of :status:`mem.mapped` exceeds the
 ``maxSize`` setting.
 
 .. seealso:: ":doc:`/administration/monitoring`."
+
+.. _sharding-chunk-migration:
+
+Chunk Migration
+~~~~~~~~~~~~~~~
+
+MongoDB migrates chunks in a :term:`shard cluster` to distribute data
+evenly among shards. Migrations may be either:
+
+- Manual. In these migrations you must specify the chunk that you want
+  to migrate and the destination shard. Only migrate chunks manually
+  after initiating sharding, to distribute data during bulk inserts,
+  or if the cluster becomes uneven. See :ref:`Migrating Chunks
+  <sharding-balancing-manual-migration>` for more details.
+
+- Automatic. The balancer process handles most migrations when
+  distribution of chunks between shards becomes uneven. See
+  :ref:`Migration Thresholds <sharding-migration-thresholds>` for more
+  details.
+
+All chunk migrations use the following procedure: 
+
+#. The balancer process sends the :dbCommand:`moveChunk` command to
+   the source shard for the chunk. In this operation the balancer
+   passes the name of the destination shard to the source shard.
+
+#. The source initaties the move with an internal
+   :dbcommand:`moveChunk` command with the destination shard.
+
+#. The destination shard begins requesting documents in the chunk, and
+   begins receiving these chunks.
+
+#. After receving the final document in the chunk, the destination
+   shard initiates a synchronization process to ensure that all
+   changes to the documents in the chunk on the source shard during
+   the migration process exist on the destination shard.
+
+   When fully synchronized, the destination shard connects to the
+   :term:`config database` and updates the chunk location in the
+   cluster metadata. After completing this operation, once there are
+   no open cursors on the chunk, the source shard starts deleting
+   its copy of documents from the migrated chunk.
+
+When the ``_secondaryThrottle`` option is set ``true`` for
+:dbcommand:`moveChunk` or the :term:`balancer`, MongoDB will ensure
+:term:`secondary` members have replicated changes before allowing new chunk
+migrations to occur.

source/reference/command/moveChunk.txt

@@ -7,8 +7,20 @@ moveChunk
 .. dbcommand:: moveChunk
 
    :dbcommand:`moveChunk` is an internal command that supports the
-   sharding functionality. Do not call directly. Use the
+   sharding functionality. Use the
    :method:`sh.moveChunk()` function in the :program:`mongo` shell if
    you must move a chunk manually.
 
+   :option _secondaryThrottle: The default setting is ``false``. If
+                               ``true`` this will specify that
+                               :term:`primary` :term:`shard` members
+                               should wait for its :term:`secondary`
+                               shard members to replicate :term:`chunk` data
+                               updates before allowing new chunk
+                               migrations to occur.
+
+			       For details on chunk migrations, please
+                               see: :ref:`Sharding Internals - Chunk
+                               Migration <sharding-chunk-migration>`
+
    .. admin-only