Skip to content

Disable balancer while indexes are inconsistent #1766

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.

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 6 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
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
19 changes: 13 additions & 6 deletions source/reference/operator/meta/orderby.txt
Original file line number Diff line number Diff line change
Expand Up @@ -29,9 +29,16 @@ $orderby
``-1``, as above) to sort in descending order or a positive value
(e.g. ``1``) to sort in ascending order.

Unless you have an index for the specified key pattern, use
:operator:`$orderby` in conjunction with :operator:`$maxScan` and/or
:method:`cursor.limit()` to avoid requiring MongoDB to perform a
large in-memory sort. The :method:`cursor.limit()` increases the
speed and reduces the amount of memory required to return this query
by way of an optimized algorithm.
Behavior
--------

The sort function requires that the entire sort be able to complete
within 32 megabytes. When the sort option consumes more than 32
megabytes, MongoDB will return an error.

To avoid this error, create an index to support the sort operation or
use :operator:`$orderby` in conjunction with :operator:`$maxScan`
and/or :method:`cursor.limit()`. The :method:`cursor.limit()` increases
the speed and reduces the amount of memory required to return this
query by way of an optimized algorithm. The specified limit must result
in a number of documents that fall within the 32 megabyte limit.
10 changes: 9 additions & 1 deletion source/tutorial/build-indexes-on-replica-sets.txt
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,15 @@ Procedure

If you need to build an index in a :term:`sharded cluster`, repeat
the following procedure for each replica set that provides each
:term:`shard`.
:term:`shard`. Also ensure the balancer has been disabled for all
collections on which you'll be creating an new index. This will prevent
an automatic index build as chunks are migrated. The balancer should be
enabled after the indexes have been updated on all shards.
Copy link
Contributor

Choose a reason for hiding this comment

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

putting this fact here is pretty awkward, because the tutorial isn't about sharded clusters, and so this fact might be weird for users in a sharded cluster. Perhaps we can put this fact somewhere else and then cross reference it here?


.. code-block:: sh

sh.disableBalancing("dbName.collectionName");


.. _tutorial-index-on-replica-sets-stop-one-member:

Expand Down
43 changes: 20 additions & 23 deletions source/tutorial/restore-sharded-cluster.txt
Original file line number Diff line number Diff line change
Expand Up @@ -28,25 +28,6 @@ Procedure
#. Stop all :program:`mongos` and :program:`mongod` processes,
including all shards *and* all config servers.

#. If shard hostnames have changed, you must manually update the
``shards`` collection in the :ref:`config-database` to use the new
hostnames. Do the following:

a. Start the three :ref:`config servers <sharding-config-server>` by
issuing commands similar to the following, using values appropriate
to your configuration:

.. code-block:: sh

mongod --configsvr --dbpath /data/configdb --port 27019

#. Restore the :ref:`config-database` on each config server.

#. Start one :program:`mongos` instance.

#. Update the :ref:`config-database` collection named ``shards`` to reflect the
new hostnames.

#. Restore the following:

- Data files for each server in each :term:`shard`. Because replica
Expand All @@ -56,14 +37,30 @@ Procedure
:ref:`backup-restore-snapshot` and :ref:`backup-restore-dump`
sections for details on these procedures.

- Data files for each :ref:`config server <sharding-config-server>`,
if you have not already done so in the previous step.
- Data files for each :ref:`config server <sharding-config-server>`.

#. Restart all the :ref:`config servers <sharding-config-server>`
:program:`mongod` instances by issuing command similar to the
following, using values appropriate
to your configuration:

.. code-block:: sh

mongod --configsvr --dbpath /data/configdb --port 27019

#. If shard hostnames **have changed**:

a. Start one :program:`mongos` instance, using the updated
config string with the new ``configdb`` hostnames and ports.

#. Update the ``shards`` collection in the :ref:`config-database` to
reflect the new hostnames.

#. Restart all the :program:`mongos` instances.
#. Stop the :program:`mongos` instance.

#. Restart all the shard :program:`mongod` instances.

#. Restart all the config servers :program:`mongod` instances.
#. Restart all the :program:`mongos` instances, making sure to use the updated config string.

#. Connect to a :program:`mongos` instance from a :program:`mongo` shell
and use the :method:`db.printShardingStatus()` method to ensure
Expand Down