Docs Menu

dropDatabase

On this page

  • Definition
  • Behavior
  • Example
dropDatabase

The dropDatabase command drops the current database, deleting the associated data files.

The command has the following form:

{ dropDatabase: 1, writeConcern: <document>, comment: <any> }

The command takes the following optional field:

Field
Description
writeConcern

Optional. A document expressing the write concern to use if greater than "majority"

{ w: <value>, j: <boolean>, wtimeout: <number> }

Omit to use the default/minimum write concern of "majority".

When issued on a replica set, if the specified write concern results in fewer member acknowledgements than write concern "majority", the operation uses "majority". Otherwise, the specified write concern is used.

When issued on a sharded cluster, MongoDB converts the specified write concern to "majority".

See also Behavior.

comment

Optional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations:

A comment can be any valid BSON type (string, integer, object, array, etc).

New in version 4.4.

mongosh also provides the helper method db.dropDatabase().

Starting in version 4.2.2, the operation takes an exclusive (X) database lock only.

In versions 3.6-4.2.1, the operation takes an exclusive (X) database lock while dropping the collections in the database but a global lock when dropping the now-empty database.

This command does not delete the users associated with the current database. To drop the associated users, run the dropAllUsersFromDatabase command in the database you are deleting.

Starting in MongoDB 4.4, the db.dropDatabase() method and dropDatabase command abort any in-progress index builds on collections in the target database before dropping the database. Aborting an index build has the same effect as dropping the built index. Prior to MongoDB 4.4, attempting to drop a database that contains a collection with an in-progress index build results in an error, and the database is not dropped.

For replica sets or shard replica sets, aborting an index on the primary does not simultaneously abort secondary index builds. MongoDB attempts to abort the in-progress builds for the specified indexes on the primary and if successful creates an associated abort oplog entry. Secondary members with replicated in-progress builds wait for a commit or abort oplog entry from the primary before either committing or aborting the index build.

Changed in version 4.4.

Replica Sets

At minimum, dropDatabase waits until all collections drops in the database have propagated to a majority of the replica set members (i.e. uses the write concern "majority").

If you specify a write concern that requires acknowledgement from fewer than the majority, the command uses write concern "majority".

If you specify a write concern that requires acknowledgement from more than the majority, the command uses the specified write concern.

Sharded Clusters

When issued on a sharded cluster, MongoDB converts the specified write concern to "majority".

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 dropDatabase command, specific to your version of MongoDB:

  • For MongoDB 4.4 and later, you must:

    1. Run the dropDatabase command on a mongos.
    2. Once the command successfully completes, run the dropDatabase command once more on a mongos.
  • For MongoDB 4.2, you must:

    1. Run the dropDatabase command on a mongos.
    2. Once the command successfully completes, run the dropDatabase command once more on a mongos.
    3. Use the flushRouterConfig command on all mongos instances before reading or writing to that database.
  • For MongoDB 4.0 and earlier, you must:

    1. Run the dropDatabase command on a mongos.
    2. Connect to each shard's primary and verify that the namespace has been dropped. If it has not, rerun the dropDatabase command again directly from the primary.
    3. Connect to a mongos, switch to the config database, and remove any reference to the removed namespace from the databases, collections, chunks, tags, and locks collections:

      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.

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

      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.

    5. Use the flushRouterConfig command on all 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 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.

Starting in MongoDB 5.0, the dropDatabase command and the db.dropDatabase() method return an error if you try to drop the admin database or the config database from a mongos.

Warning

Dropping the admin database or the config database can leave your cluster in an unusable state.

The db.dropDatabase() method and dropDatabase create an invalidate Event for any Change Streams opened on the dropped database or opened on the collections in the dropped database.

The following example in mongosh uses the use <database> operation to switch the current database to the temp database and then uses the dropDatabase command to drop the temp database:

use temp
db.runCommand( { dropDatabase: 1 } )
Tip
See also:
Give Feedback
© 2021 MongoDB, Inc.

About

  • Careers
  • Legal Notices
  • Privacy Notices
  • Security Information
  • Trust Center
© 2021 MongoDB, Inc.