Skip to content

Commit dea325e

Browse files
author
Sam Kleinman
committed
DOCS-306: edits and clarification
1 parent c851e29 commit dea325e

File tree

2 files changed

+30
-17
lines changed

2 files changed

+30
-17
lines changed

source/administration/sharding.txt

Lines changed: 12 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -548,7 +548,7 @@ However, you may want to migrate chunks manually in a few cases:
548548
- If the balancer in an active cluster cannot distribute chunks within
549549
the balancing window, then you will have to migrate chunks manually.
550550

551-
To migrate chunks, use the :dbcommand:`moveChunk` command.
551+
To migrate chunks, use the :dbcommand:`moveChunk` command.
552552

553553
.. note::
554554

@@ -577,22 +577,26 @@ This command moves the chunk that includes the shard key value "smith" to the
577577
block until the migration is complete.
578578

579579
.. versionadded:: 2.2
580-
:dbcommand:`moveChunk` command now has the : ``_secondaryThrottle``
580+
:dbcommand:`moveChunk` command has the: ``_secondaryThrottle``
581581
paramenter. When set to ``true``, MongoDB ensures that
582582
:term:`secondary` members have replicated operations before allowing
583583
new chunk migrations.
584584

585585
.. warning::
586586

587-
The :dbcommand:`moveChunk` command may produce an error message:
587+
The :dbcommand:`moveChunk` command may produce the following error
588+
message:
588589

589590
.. code-block:: none
590591

591592
The collection's metadata lock is already taken.
592593

593-
when there are open :term:`cursors <cursor>` accessing the chunk to
594-
be moved. To fix this situation, either wait until the cursors
595-
complete their operation or remove the cursors.
594+
These errors occur when clients have too many open :term:`cursors
595+
<cursor>` that access the chunk you are migrating. You can either
596+
wait until the cursors complete their operation or close the
597+
cursors manually.
598+
599+
.. TODO insert link to killing a cursor.
596600

597601
.. index:: balancing; operations
598602
.. _sharding-balancing-operations:
@@ -718,8 +722,8 @@ be able to migrate chunks:
718722
patterns, it is important to ensure that the balancing window you
719723
select will be sufficient to support the needs of your deployment.
720724

721-
Remove Balancing Window Schedule
722-
--------------------------------
725+
Remove a Balancing Window Schedule
726+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
723727

724728
If you have :ref:`set the balancing window
725729
<sharding-schedule-balancing-window>` and wish to remove the schedule

source/faq/sharding.txt

Lines changed: 18 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -332,14 +332,23 @@ hashed value in your application and include this value in your
332332
documents for use as a shard key, the :issue:`SERVER-2001` issue will
333333
implement this capability within MongoDB.
334334

335-
What does "ERROR: moveChunk commit failed: version is at X|Y instead of A|B" and "ERROR: TERMINATING" mean? What happened?
336-
--------------------------------------------------------------------------------------------------------------------------
335+
What do ``moveChunk commit failed`` errors mean?
336+
------------------------------------------------
337337

338-
During a :ref:`chunk migration <sharding-chunk-migration>`, the
339-
:term:`shard` could not connect to the :term:`config database` to update
340-
chunk information. If the shard cannot update the config database
341-
after :dbcommand:`moveChunk`, the shard cluster will have an
342-
inconsistent view of all chunks. For this situation, the shard will
343-
terminate itself to prevent data inconsistency and produce this error.
338+
Consider the following error message:
344339

345-
Please contact MongoDB support directly for help in resolving this situation.
340+
.. code-block:: none
341+
342+
ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"
343+
344+
:program:`mongod` procudes this message if, during a :ref:`chunk
345+
migration <sharding-chunk-migration>`, the term:`shard` could not
346+
connect to the :term:`config database` to update chunk information. If
347+
the shard cannot update the config database after
348+
:dbcommand:`moveChunk`, the shard cluster will have an inconsistent
349+
view of all chunks. For this situation, the shard will terminate
350+
itself to prevent data inconsistency.
351+
352+
If you encounter this issue, contact the `MongoDB User Group
353+
<http://groups.google.com/group/mongodb-user>`_ or 10gen support to
354+
address this issue.

0 commit comments

Comments
 (0)