Skip to content

Minor rewrites #1436

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Minor rewrites #1436

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2f3bd3e
Minor rewrites
Dec 2, 2013
e9494d5
some more fixes
Dec 17, 2013
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 22 additions & 25 deletions source/faq/sharding.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -236,12 +236,11 @@ not cause concern.
How should administrators deal with failed migrations?
------------------------------------------------------

Failed migrations require no administrative intervention. Chunk moves are
consistent and deterministic.

If a migration fails to complete for some reason, the :term:`cluster`
will retry the operation. When the migration completes successfully,
the data will reside only on the new shard.
Failed migrations require no administrative intervention. Chunk
migrations always preserve a consistent state. If a migration
fails to complete for some reason, the :term:`cluster` retries
the operation. When the migration completes successfully, the data
resides only on the new shard.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Failed migrations require no administrative intervention. Chunk
migrations always preserve a consistent state. If a migration
fails to complete for some reason, the :term:cluster retries
the operation. When the migration completes successfully, the data
resides only on the new shard.


What is the process for moving, renaming, or changing the number of config servers?
-----------------------------------------------------------------------------------
Expand Down Expand Up @@ -355,28 +354,26 @@ To address this issue, MongoDB 2.4 provides :ref:`hashed shard keys
What do ``moveChunk commit failed`` errors mean?
------------------------------------------------

Consider the following error message:
At the end of a :ref:`chunk migration <sharding-chunk-migration>`, the
:term:`shard` must connect to the :term:`config database` to update
the chunk's record in the cluster metadata. If the :term:`shard`
fails to connect to the :term:`config database`, MongoDB reports the
following error:

.. code-block:: none

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"

:program:`mongod` issues this message if, during a :ref:`chunk
migration <sharding-chunk-migration>`, the :term:`shard` could not
connect to the :term:`config database` to update chunk information at
the end of the migration process. If
the shard cannot update the config database after
:dbcommand:`moveChunk`, the cluster will have an inconsistent
view of all chunks. In these situations, the :term:`primary` member of
the shard will terminate
itself to prevent data inconsistency. If the :term:`secondary` member
can access the config database, the shard's data will be
accessible after an election. Administrators will need to resolve the
chunk migration failure independently.

If you encounter this issue, contact the `MongoDB User Group
<http://groups.google.com/group/mongodb-user>`_ or MongoDB support to
address this issue.
ERROR: moveChunk commit failed: version is at <n>|<nn> instead of
<N>|<NN>" and "ERROR: TERMINATING"

When this happens, the :term:`primary` member of the shard's replica
set then terminates to protect data consistency. If a :term:`secondary`
member can access the config database, data on the shard becomes
accessible again after an election.

The user will need to resolve the chunk migration failure
independently. If you encounter this issue, contact the `MongoDB
User Group <http://groups.google.com/group/mongodb-user>`_ or
:about:`MongoDB Support </support>` to address this issue.

How does draining a shard affect the balancing of uneven chunk distribution?
----------------------------------------------------------------------------
Expand Down