db.dropDatabase()¶

On this page

Definition
Behavior
Example

Definition¶

db.dropDatabase()¶: Removes the current database, deleting the associated data files.

Behavior¶

The db.dropDatabase() wraps the dropDatabase command. To specify a write concern, use the dropDatabase command.

Locks¶

Starting in versions 3.6, 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.

User Management¶

Changed in version 2.6: 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.

Replica Set and Sharded Clusters¶

Replica Sets

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

To specify a write concern greater than the minimum write concern of "majority", use the dropDatabase command.

Sharded Clusters

When issued on a sharded cluster, MongoDB converts the write concern of the dropDatabase command 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 with MongoDB 4.0 or previous:

Run the dropDatabase command on a mongos.
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.

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:

copy

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 primary of each shard, and remove any reference to the removed namespace from the cache.databases, cache.collections, and cache.chunks.DATABASE.COLLECTION collections:

copy

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 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.

Change Streams¶

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

Example¶

The following example in the mongo shell uses the use <database> operation to switch the current database to the temp database and then uses the db.dropDatabase() method to drops the temp database:

copy

use temp
db.dropDatabase()