Skip to content

DOCS-14619 clarify dropDatabases sharded cluster procedure #5503

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

Merged
merged 1 commit into from
Jul 6, 2021
Merged
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
104 changes: 70 additions & 34 deletions source/includes/warning-dropDatabase-shardedCluster.rst
Original file line number Diff line number Diff line change
@@ -1,34 +1,70 @@
.. warning::

Starting in MongoDB 4.2:
If you drop a database and create a new database with the same name, you
must either:

- Restart all :binary:`~bin.mongos` instances and all
:binary:`~bin.mongod` shard members (including the secondary
members);

- Use the :dbcommand:`flushRouterConfig` command on all
:binary:`~bin.mongos` instances and all :binary:`~bin.mongod`
shard members (including the secondary members) before reading
or writing to that database.

This ensures that the :binary:`~bin.mongos` and shard instances
refresh their metadata cache, including the location of the
:ref:`primary shard <primary-shard>` for the new database.

Otherwise, the you may miss data on reads, and may not write data to
the correct shard. To recover, you must manually intervene.

In MongoDB 4.0 and earlier:
If you drop a database and create a new database with the same name, you
must either restart all :binary:`~bin.mongos` instances, or use the
:dbcommand:`flushRouterConfig` command on all :binary:`~bin.mongos`
instances before reading or writing to that database. This
ensures that the :binary:`~bin.mongos` instances refresh their
metadata cache, including the location of the :ref:`primary shard
<primary-shard>` for the new database.

Otherwise, the you may miss data on reads, and may not write data to
the correct shard. To recover, you must manually intervene.

If you intend to create a new database with the same name as the dropped
database, you must follow these additional steps for using the
:dbcommand:`dropDatabase` command, specific to your version of MongoDB:

- For **MongoDB 4.2**, you must:

#. Run the :dbcommand:`dropDatabase` command on a
:binary:`~bin.mongos`.

#. Once the command successfully completes, run the
:dbcommand:`dropDatabase` command once more on a
:binary:`~bin.mongos`.

#. Use the :dbcommand:`flushRouterConfig` command on **all**
:binary:`~bin.mongos` instances before reading or writing to that
database.

- For **MongoDB 4.0 and earlier**, you must:

#. Run the :dbcommand:`dropDatabase` command on a
:binary:`~bin.mongos`.

#. Connect to each shard's :term:`primary` and verify that the
namespace has been dropped. If it has not, rerun the
:dbcommand:`dropDatabase` command again directly from the
:term:`primary`.

#. Connect to a :binary:`~bin.mongos`, switch to the
:term:`config database`, and remove any reference to the removed
namespace from the ``databases``, ``collections``, ``chunks``,
``tags``, and ``locks`` collections:

.. code-block:: javascript

use config
db.collections.remove( { _id: /^DATABASE\./ }, {writeConcern: {w: 'majority' }} )
db.databases.remove( { _id: "DATABASE" }, {writeConcern: {w: 'majority' }} )
db.chunks.remove( { ns: /^DATABASE\./ }, {writeConcern: {w: 'majority' }} )
db.tags.remove( { ns: /^DATABASE\./ }, {writeConcern: {w: 'majority' }} )
db.locks.remove( { _id: /^DATABASE\./ }, {writeConcern: {w: 'majority' }} )

Where ``DATABASE`` represents the namespace of the database you
just dropped.

#. Connect to the :term:`primary` of each shard, and remove any
reference to the removed namespace from the ``cache.databases``,
``cache.collections``, and ``cache.chunks.DATABASE.COLLECTION``
collections:

.. code-block:: javascript

db.getSiblingDB("config").cache.databases.remove({_id:"DATABASE"}, {writeConcern: {w: 'majority' }});
db.getSiblingDB("config").cache.collections.remove({_id:/^DATABASE.*/}, {writeConcern: {w: 'majority' }});
db.getSiblingDB("config").getCollectionNames().forEach(function(y) {
if(y.indexOf("cache.chunks.DATABASE.") == 0)
db.getSiblingDB("config").getCollection(y).drop()
})

Where ``DATABASE`` represents the namespace of the database you
just dropped.

#. Use the :dbcommand:`flushRouterConfig` command on **all**
:binary:`~bin.mongos` instances before reading or writing to that
database.

These steps ensure that all cluster nodes refresh their metadata cache,
which includes the location of the :ref:`primary shard<primary-shard>`
for the new database. Otherwise, you may miss data on reads, and may not
write data to the correct shard. To recover, you must manually
intervene.
2 changes: 1 addition & 1 deletion source/reference/command/dropDatabase.txt
Original file line number Diff line number Diff line change
Expand Up @@ -82,7 +82,7 @@ User Management
Replica Set and Sharded Clusters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. versionchanged:: 3.6
.. versionchanged:: 4.2

Replica Sets
At minimum, :dbcommand:`dropDatabase` waits until all collections
Expand Down