[SERVER-2079] Authenticated Connections do not get terminated when dropDatabase() command is issued. Created: 09/Nov/10 Updated: 08/Mar/13 Resolved: 28/Feb/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 1.6.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Justin Smestad | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 5 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
ubuntu 10.04 |
||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
If the user has an active connection to a particular database, with the server running in an authenticated environment, if you go into the MongoDB shell and execute a `db.dropDatabase()` or `db.getSisterDB('db_name').dropDatabase()` the data is dropped, but the authenticated connections are left open allowing the system to recreate the database. A temporary workaround is to restart /etc/networking to kill all active connections or restart mongodb for it to take effect. This is a pretty big bug for the MongoDB hosts out there like ourselves. Here is a gist below of what the log output says: https://gist.github.com/9a6e2b1b81917d18b11c Tue Nov 9 04:31:41 [conn65729] run command clobby-staging.$cmd { dropDatabase: 1.0 }Tue Nov 9 04:31:41 [conn65729] dropDatabase clobby-staging Tue Nov 9 04:31:41 [conn65729] run command clobby-staging.$cmd { dropDatabase: 1.0 }Tue Nov 9 04:31:41 [conn65729] dropDatabase clobby-staging } bytes:105 nreturned:1 3282ms reslen:81 12ms Tue Nov 9 04:31:42 [conn65447] Accessing: clobby-staging for the first time for clobby-staging.rooms } bytes:184 nreturned:1 798ms |
| Comments |
| Comment by David Cardon [ 28/Feb/13 ] |
|
Sorry, I should clarify my example, because I don't believe the duplicate you identify is a duplicate. Here's the full process: Cluster routing service domain: mongos Main write process = M M authenticates against: mongos/admin C foo_z.bar.ensureIndex({l:1}); (mongo assigns foo_z.bar to bob) F foo_z.bar.insert({...} ) => which directs writes to bob/foo_z.bar ); (mongo assigns foo_z.bar to chuck this time around) F foo_z.bar.insert({...} ) => which STILL directs writes to bob/foo_z.bar (even though config collections state that foo_z.bar resides on chuck) So, I'm not removing any users or databases whose credentials should be invalidated. My admin credentials are still perfectly valid in this process. |
| Comment by Scott Hernandez (Inactive) [ 28/Feb/13 ] |
|
David, what you are talking about is very different, and related to issues in mongos or the client app. The former will be fixed in 2.4 since we uniquely identify collections which have the same name but are different instances in mongos/sharded-clusters (using a unique ObjectId for each instance). |
| Comment by David Cardon [ 28/Feb/13 ] |
|
Here is (I think) one of the side effects of this issue that we are seeing:
Example: Cluster shard domains: alice, bob, chuck ); (mongo assigns foo_z.bar to bob) ); (mongo assigns foo_z.bar to chuck |
| Comment by Anthony Crumley [ 01/May/11 ] |
|
Justin, I am working on this one but it is my first attempt at a MongoDB contribution so we will see how it works out. |
| Comment by Justin Smestad [ 01/May/11 ] |
|
Is there any movement on this? |