[DOCS-11488] Document that dropDatabase in 3.6 now waits for replication internally Created: 26/Mar/18  Updated: 30/Oct/23  Resolved: 26/Mar/18

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Unassigned
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to DOCS-10541 Docs for SERVER-29277: Two Phase Drop... Closed
Participants:
Days since reply: 5 years, 46 weeks, 2 days ago

 Description   

In 3.6, the behavior of the dropDatabase command changed a bit. What we now do is:

  • Take the global exclusive lock
  • Mark the database as drop-pending, which will prevent new collections from being created on the database
  • Drop every collection in the database
  • Release the global exclusive lock
  • Wait for the collection drops to replicate to a majority
  • Re-take the global exclusive lock
  • Drop the database catalog entry
  • Release locks and return
  • [optionally wait for user-provided write concern to replicate the write that dropped the database catalog entry]


 Comments   
Comment by Spencer Brody (Inactive) [ 26/Mar/18 ]

Looks like we already have this line in the docs

"Changed in version 3.6: dropDatabase waits until all collections drops in the database have propagated to a majority of the replica set members."

That seems sufficient

Comment by Spencer Brody (Inactive) [ 26/Mar/18 ]

CC benety.goh to confirm the behavior matches what I described above

Generated at Thu Feb 08 08:02:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.