[SERVER-2329] Dropped database doesn't disappear due to replication Created: 04/Jan/11 Updated: 06/Dec/22 Resolved: 23/Nov/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 1.6.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Justin Dearing | Assignee: | Backlog - Replication Team |
| Resolution: | Done | Votes: | 13 |
| Labels: | repl1, sync | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows 2008 Datacenter edition |
||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||||||||||||||
| Operating System: | Windows | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Description |
|
I'm calling db.dropDatabase() on a master of a master slave pair on windows, and it doesn't stay deleted. Console log: > db.getSisterDB('staging_KMI').dropDatabase() { "dropped" : "staging_KMI", "ok" : 1 }> show dbs > use staging_KMI > show dbs Master/slave stuff Config on the master: "C:\Program Files\10gen\mongodb-win32-x86_64-1.6.4\bin\mongod.exe" --service --logpath c:\data\logs\mongo-master.log --logappend --master --bind_ip localhost Log on the master: Slave configuration: "C:\Program Files\10gen\mongodb-win32-x86_64-1.6.4\bin\mongod.exe" --service --logpath c:\data\logs\mongo-slave.log --logappend --dbpath c:\data\db_slave --slave --source localhost --port 27018 --bind_ip localhost Log on the slave: Tue Jan 04 14:48:55 [replslave] repl: applied 4 operations |
| Comments |
| Comment by Spencer Brody (Inactive) [ 23/Nov/16 ] | ||||
|
We don't believe the original issue in this ticket still exists. If anyone is still seeing databases recreated due to replication, please file a new issue. Note that | ||||
| Comment by Matt Muscari [ 31/May/13 ] | ||||
|
Due to database-level locking rather than collection-level locking, we end up creating and deleting databases around every 10 minutes. Our current workaround involves letting old databases sit for some time before deleting them, in which case they usually will drop successfully. Taking the server offline is not an option for our environment. | ||||
| Comment by Kenny Gorman [ 09/Apr/13 ] | ||||
|
This really should be prioritized into 2.4.x because it's such a horrible experience to have to stepDown() to get dropDatabase() to essentially 'work'. | ||||
| Comment by Gerric Chaplin [ 05/Apr/13 ] | ||||
|
Bumping for the greater good. Still an issue in 2.4.1.
And two had the same name but were empty.
I did attempted to remove these DBs on the master but I had no luck. The empty DBs did not seem to be copied to the other nodes in the Replica Set. What I did to fix it: | ||||
| Comment by David Trefou [ 21/Jan/13 ] | ||||
|
We are also having this issue with a sharded database over 3 replicaset. mongos> show dbs mongos> show dbs | ||||
| Comment by Bob Kuhar [ 08/Oct/12 ] | ||||
|
We're using plain-jane replication and have this issue. For some databases I can... | ||||
| Comment by Jason R. Coombs [ 17/Sep/12 ] | ||||
|
We're experiencing this issue as well. MongoDB 2.0.6. | ||||
| Comment by auto [ 25/Apr/12 ] | ||||
|
Author: {u'login': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@10gen.com'}Message: Skip test that fails due to | ||||
| Comment by Mathieu Poumeyrol [ 08/Aug/11 ] | ||||
|
I have a very similar issue on a sharded and RS system: > db.getCollectionNames() | ||||
| Comment by Bernie Hackett [ 02/Jun/11 ] | ||||
|
From the slave log while the tests are running. Seems related: Wed Jun 1 21:07:37 [replslave] repl: applied 1002 operations | ||||
| Comment by Bernie Hackett [ 02/Jun/11 ] | ||||
|
My tests were run with 1.8.1 and newer. | ||||
| Comment by Bernie Hackett [ 02/Jun/11 ] | ||||
|
I should also point out that these tests pass running against a single instance of mongod (obviously the master_slave_connection test doesn't run that way). | ||||
| Comment by Bernie Hackett [ 02/Jun/11 ] | ||||
|
I'm seeing the same problem on OSX and Linux x86_64. Steps to reproduce: Start up a master on the port 27017 Run the pymongo unittest suite using nose: One or more of the following tests will fail checking if a database name exists after trying to drop the database: ====================================================================== ====================================================================== ====================================================================== If you then log into the mongo shell you can see that the test dbs are listed as empty and can't be deleted: > show dbs > use local | ||||
| Comment by Justin Dearing [ 04/Jan/11 ] | ||||
|
I meant master/slave. I have one master one slave on the same hardware. Slave goes down once a day for backups. Nothing queries the slave. Configured based on these directions: | ||||
| Comment by Eliot Horowitz (Inactive) [ 04/Jan/11 ] | ||||
|
Do you mean replica pairs? or something else? |