[SERVER-33272] The DatabaseHolder::close() function no longer requires a global write lock and neither does the dropDatabase command. Created: 12/Feb/18 Updated: 29/Oct/23 Resolved: 09/Oct/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1, 4.2.2 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Gregory Wlodarek |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.2
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Execution Team 2019-08-12, Execution Team 2019-08-26, Execution Team 2019-09-09, Execution Team 2019-09-23, Execution Team 2019-10-07, Execution Team 2019-10-21 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
We can demote the lock needed for DatabaseHolder::close() from an exclusive global lock to a database exclusive lock as the DatabaseHolder is protected by a mutex. With this, we can also remove the exclusive global locks needed in the dropDatabase command. Old Description: To fix this, we can check to see if a database is empty (i.e., no collection entries remain in the catalog) after a collection drop. If it is indeed empty, we can attempt to close the database by locking it in X mode and calling DatabaseHolder::close(). |
| Comments |
| Comment by Githook User [ 16/Oct/19 ] |
|
Author: {'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'}Message: |
| Comment by Gregory Wlodarek [ 09/Oct/19 ] |
|
The work for this ticket has been committed here. |
| Comment by Gregory Wlodarek [ 09/Oct/19 ] |
|
Please see SERVER-43925 for the continuation of the ticket for proactively close newly empty databases. |
| Comment by Gregory Wlodarek [ 08/Oct/19 ] |
|
After discussing with the team, we're going to set this ticket aside as there's no urgency for it right now and needs more work to be done before tackling it.
This is problematic to do today because if we remove the Database in the DatabaseHolder when the last collection is dropped, then we lose our isDropPending flag (a member of the Database object class). This flag prevents new collections from being created on the database while waiting for the second phase of collection drops to be majority committed when using majority read concern. Timeline of events if we implicitly close empty databases today Client 1:
Client 2:
Client 1:
Another issue that would occur is during rollback. When the last collection is first phase dropped and rollback occurs, the Database object will no longer exist in the DatabaseHolder. |
| Comment by Githook User [ 27/Aug/19 ] |
|
Author: {'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'name': 'Gregory Wlodarek'}Message: Revert " This reverts commit 40f226b5a9bfb4863268334d287a46fb226a22cf. |
| Comment by Githook User [ 27/Aug/19 ] |
|
Author: {'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}Message: |
| Comment by Githook User [ 23/Aug/19 ] |
|
Author: {'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'name': 'Gregory Wlodarek'}Message: Revert " This reverts commit b6b81f34516ba7b1472cb1dd319da8785f24ae58. |
| Comment by Githook User [ 23/Aug/19 ] |
|
Author: {'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}Message: |
| Comment by Githook User [ 23/Aug/19 ] |
|
Author: {'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'name': 'Gregory Wlodarek'}Message: |
| Comment by Eric Milkie [ 02/Jan/19 ] |
|
After some discussion with Esha, I have decided to pull this QW ticket from the project, as it will exacerbate an existing problem with unsharded databases. See |
| Comment by Esha Maharishi (Inactive) [ 02/Jan/19 ] |
|
This may have implications for sharding, since the list of databases is also stored in the routing table on the config server. |