[SERVER-13758] dropDatabase take global lock too long Created: 28/Apr/14  Updated: 06/Dec/22  Resolved: 06/Oct/17

Status: Closed
Project: Core Server
Component/s: Concurrency
Affects Version/s: 2.6.0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: chensi Assignee: Backlog - Storage Execution Team
Resolution: Done Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Participants:

 Description   

dropDatabase acquire the global lock when running
When I want to drop database whose size is 600GB, deleting files will take half a minitue, So the global lock is taken for half a minitue, the whole mongod instance won't service during these time.



 Comments   
Comment by Eric Milkie [ 06/Oct/17 ]

As of version 3.6, dropDatabase has been changed to drop collections individually first before removing the database, and these drops do not hold a Global lock but instead hold the database lock being dropped.

Comment by Jason R. Coombs [ 17/Aug/16 ]

Depending on the system and the DB size, deleting files could take much longer than half a minute. We recently attempted to drop a database that was 2TB. After 15 minutes, it was down to 1.8TB, and in the meantime, all requests were just queuing up. We ended up killing the server to recover. Either dropDatabase needs to be much faster or there needs to be a better technique for lock acquisition. Perhaps a lock could be taken for that db (by name) but not globally for the server.

I think there may be a workaround - first delete the bulk of the database by deleting docs or collections in the database until it's consuming only a small amount of space (<2GB). Then, on the secondary members, run repairDatabase, which will take the global write lock and remove the bulk of the file allocations. Next, step down the primary and do the same on it. Finally, drop the database, which should now be small and complete quickly. Would that work?

Generated at Thu Feb 08 03:32:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.