[SERVER-20638] Reading the profiling level shouldn't create databases that don't exist Created: 23/Sep/15 Updated: 28/Oct/15 Resolved: 30/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.0.7, 3.1.9 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Cailin Nelson | Assignee: | Mathias Stearn |
| Resolution: | Done | Votes: | 0 |
| Labels: | mms-s | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Minor Change | ||||||||
| Operating System: | ALL | ||||||||
| Backport Completed: | |||||||||
| Sprint: | QuInt A (10/12/15) | ||||||||
| Participants: | |||||||||
| Description |
|
Currently the profile command always creates the database even if it doesn't exist. The plan is to keep that behavior when setting the profiling level, but to return the server-wide default level without creating the database when just reading the profiling level. Original Description: I am seeing hundreds of instances of failures to drop a database on a secondary in our cloud-dev environment. Here is one example. Primary (WT)
Longer snippet.... note that it is dropped only once (but there are two collections here that have very similar names, dropped back to back).
Secondary (3.0.6 mmapv1)
Longer snippet.... note that it is dropped only once (but there are two collections here that have very similar names, dropped back to back). After the drop, the collection is recreated.
The listDatabases command here is from the monitoring agent, it's a complete coincidence that it arrives in the vicinity of these drops. It is not executed by the Java application code that is dropping databases.
Full secondary log: https://jira.mongodb.org/secure/attachment/91141/mongodb.log.2015-09-16T23-18-52.txt |
| Comments |
| Comment by Githook User [ 30/Sep/15 ] | ||||||||||||||||||||||||||||||||
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: Setting the profiling level will still create the database. (cherry picked from commit e5883822fd2fc777fd3e3e6b766f54e2caa8e594) | ||||||||||||||||||||||||||||||||
| Comment by Githook User [ 30/Sep/15 ] | ||||||||||||||||||||||||||||||||
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: Setting the profiling level will still create the database. | ||||||||||||||||||||||||||||||||
| Comment by Daniel Pasette (Inactive) [ 25/Sep/15 ] | ||||||||||||||||||||||||||||||||
|
In the long term, we should determine where we can change this auto-create "feature" from the rest of the users of OldClientContext. In the short term, we should change the profile cmd to not auto-create the db if it doesn't exist. This can be backported to v3.0 | ||||||||||||||||||||||||||||||||
| Comment by Cailin Nelson [ 25/Sep/15 ] | ||||||||||||||||||||||||||||||||
|
Interesting. Do you consider this to be a MongoDB bug? With the current functionality, it is impossible for an application to ask for the profiling level and guarantee that it is not accidentally creating a database when doing so. For example, what's going here is that there are two threads:
... and the drop is happening between the two Monitoring Agent actions. There is no way to coordinate the actions of these two applications. | ||||||||||||||||||||||||||||||||
| Comment by Mathias Stearn [ 25/Sep/15 ] | ||||||||||||||||||||||||||||||||
|
Looks like the actual problem is that profile (along with a few other commands) creates the database if it does not exist. It looks like you are trying to query for the profiling level (from conn30216) which is causing the database to be resurrected. | ||||||||||||||||||||||||||||||||
| Comment by Daniel Pasette (Inactive) [ 23/Sep/15 ] | ||||||||||||||||||||||||||||||||
|
Mathias, | ||||||||||||||||||||||||||||||||
| Comment by Cailin Nelson [ 23/Sep/15 ] | ||||||||||||||||||||||||||||||||
|
Here is another example: Does not exist on the primary:
Does exist on the secondary:
Secondary log for the drop suggests a recreation via the listDatabases command
|