You can use
db.dropDatabase() for deployments hosted in the following
MongoDB Atlas: The fully managed service for MongoDB deployments in the cloud
db.dropDatabase() method takes an optional parameter:
Omit to use the default/minimum write concern of
When issued on a replica set, if the specified write concern
results in fewer member acknowledgements than write concern
See also Behavior.
New in version 4.2.
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.
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
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.
- Replica Sets
Starting in MongoDB 4.2, you can specify a write concern to the method. If you specify a write concern that requires acknowledgement from fewer than the majority, the method uses write concern
If you specify a write concern that requires acknowledgement from more than the majority, the method uses the specified write concern.
- Sharded Clusters
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
dropDatabasecommand, specific to your version of MongoDB:
For MongoDB 5.0 and later, you must:
For MongoDB 4.4, you must:
For MongoDB 4.2, you must:
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.
use temp db.dropDatabase()