[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 |
| 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? |