[SERVER-13526] db.dropDatabase is not erasing the database entry from the configdb config.collections Created: 09/Apr/14  Updated: 22/Jan/15  Resolved: 10/Jun/14

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 2.4.9
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Björn Bullerdieck [X] Assignee: Thomas Rueckstiess
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Operating System: ALL
Participants:

 Description   

>create databases "test1" -"test10" activate sharding
>create one collection "coll1" in each database + activate sharding (hashed shard key)
>insert documents

>drop databases

>ceate databases "test1" -"test10"..
>try activate sharding
=>

Command: { "shardCollection" : "test1.coll1" , "key" : { "_id" : "hashed"}}. Know error msg: already sharded

config.collections
{
  "_id" : "test1.coll1",
  "lastmod" : ISODate("1970-01-17T04:04:12.228Z"),
  "dropped" : true
}

in config.databases "test1"-"test10" is dropped.

SERVER-2253



 Comments   
Comment by Ramon Fernandez Marina [ 10/Jun/14 ]

Hi Björn Bullerdieck,

we haven't heard back from you for some time, so I'm going to mark this ticket as resolved. If this is still an issue for you, feel free to re-open it and upload the test program you're using so we can try to reproduce the problem on our end.

Regards,
Ramón.

Comment by Thomas Rueckstiess [ 20/May/14 ]

Hi Björn,

I haven't heard back from you on this issue and would still require the test program you're using as we can't reproduce the issue. Please let us know if you're able to provide the script and the log file that shows the issue from database creation to drop.

Kind Regards,
Thomas

Comment by Thomas Rueckstiess [ 01/May/14 ]

Hi Björn,

I've repeated the test with balancing enabled and it still works fine for me. After the drop, the databases are removed and the listDatabases command (which is used by the Java driver when calling mongo.getDatabaseNames()) does not show them anymore.

I feel like I haven't understood what exactly the problem is here. Is the issue that you call dropDatabase() but the database does not get dropped correctly?

To continue the diagnosis, can you please provide your Java test program that you use to reproduce the issue, and the full log file from start to end that shows how the databases are created and dropped (or not dropped).

Thanks,
Thomas

Comment by Björn Bullerdieck [X] [ 10/Apr/14 ]

on our other shard test system we get the direct opposite. db.dropDatabase() does not drop the database + collection on the ReplicaSets.
4 rs
3 config
2 mongos

mongos> show databases
admin   (empty)
config  0.109375GB
..
ci_400000000000003 0.609375GB
 
shards:
        {  "_id" : "shard_001",  "host" : "rs1/rs1-a:27017,rs1-b:27017" }
        {  "_id" : "shard_002",  "host" : "rs2/rs2-a:27017,rs2-b:27017" }
        {  "_id" : "shard_003",  "host" : "rs3/rs3-a:27017,rs3-b:27017" }
        {  "_id" : "shard_004",  "host" : "rs4/rs4-a:27017,rs4-b:27017" }
  databases:
        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
        {  "_id" : "test",  "partitioned" : false,  "primary" : "shard_001" }

Comment by Björn Bullerdieck [X] [ 10/Apr/14 ]

ok.
=> Drop with balancer sometimes not worked completely. sh.status() shows these databases. Collections are correct ("dropped" : true).
but
1.
we only drop the databases in the test if the check "mongo.getDatabaseNames().contains(database)" (java) returns true. But it returns false.

mongos> sh.status()
--- Sharding Status ---
  sharding version: {
        "_id" : 1,
        "version" : 3,
        "minCompatibleVersion" : 3,
        "currentVersion" : 4,
        "clusterId" : ObjectId("53466c3bb5590887dff49876")
}
  shards:
        {  "_id" : "shard_001",  "host" : "WT-INT34:20117" }
        {  "_id" : "shard_002",  "host" : "WT-INT34:20217" }
        {  "_id" : "shard_003",  "host" : "WT-INT34:20317" }
        {  "_id" : "shard_004",  "host" : "WT-INT34:20417" }
  databases:
        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
        {  "_id" : "test",  "partitioned" : false,  "primary" : "shard_002" }
        {  "_id" : "ci_400000000000003",  "partitioned" : true,  "primary" : "shard_001" }
        {  "_id" : "ci_400000000000005",  "partitioned" : true,  "primary" : "shard_001" }
        {  "_id" : "ci_400000000000009",  "partitioned" : true,  "primary" : "shard_001" }
        {  "_id" : "ci_400000000000002",  "partitioned" : true,  "primary" : "shard_001" }
        {  "_id" : "ci_400000000000007",  "partitioned" : true,  "primary" : "shard_001" }
 
mongos> show databases
admin   (empty)
config  0.015625GB

2. If you try to activate sharding on a droped collection of these databases, it fails.

Comment by Björn Bullerdieck [X] [ 10/Apr/14 ]

We didn't stop the balancer and I was able to reproduce the behavior with activated balancer.
4 single mongodb
3 config
1 mongos

>create databases "ci_400000000000001" -"ci_400000000000010" activate sharding
>create one collection "coll1" in each database + activate sharding (hashed shard key)
>insert documents
>drop databases

LOGS

Thu Apr 10 12:16:02.521 [conn37] DROP DATABASE: ci_400000000000002
Thu Apr 10 12:16:02.521 [conn37] erased database ci_400000000000002 from local registry
Thu Apr 10 12:16:02.522 [conn37] ChunkManager: time to load chunks for ci_400000000000002.customer_informations: 0ms sequenceNumber: 241 version: 3|1||53466f42b5590887dff4990f based on: (empty)
Thu Apr 10 12:16:02.523 [conn37] ChunkManager: time to load chunks for ci_400000000000002.customer_informations: 0ms sequenceNumber: 242 version: 3|1||53466f42b5590887dff4990f based on: (empty)
Thu Apr 10 12:16:02.523 [conn37] DBConfig::dropDatabase: ci_400000000000002
Thu Apr 10 12:16:02.523 [conn37] about to log metadata event: { _id: "WT-INT34-2014-04-10T10:16:02-53466f62b5590887dff4991f", server: "WT-INT34", clientAddr: "N/A", time: new Date(1397124962523), what: "dropDatabase.start", ns: "ci_400000000000002", details: {} }
Thu Apr 10 12:16:02.642 [Balancer] couldn't find database [ci_400000000000002] in config db
Thu Apr 10 12:16:02.678 [conn37] about to log metadata event: { _id: "WT-INT34-2014-04-10T10:16:02-53466f62b5590887dff49920", server: "WT-INT34", clientAddr: "N/A", time: new Date(1397124962678), what: "dropCollection.start", ns: "ci_400000000000002.customer_informations", details: {} }
Thu Apr 10 12:16:02.712 [Balancer] 	 put [ci_400000000000002] on: shard_004:WT-INT34:20417
Thu Apr 10 12:16:02.713 [Balancer] ChunkManager: time to load chunks for ci_400000000000002.customer_informations: 0ms sequenceNumber: 243 version: 3|1||53466f42b5590887dff4990f based on: (empty)
Thu Apr 10 12:16:03.092 [conn37] distributed lock 'ci_400000000000002.customer_informations/WT-INT34:27017:1397124154:41' acquired, ts : 53466f62b5590887dff49921
Thu Apr 10 12:16:03.257 [conn37] about to log metadata event: { _id: "WT-INT34-2014-04-10T10:16:03-53466f63b5590887dff49922", server: "WT-INT34", clientAddr: "N/A", time: new Date(1397124963257), what: "dropCollection", ns: "ci_400000000000002.customer_informations", details: {} }
Thu Apr 10 12:16:03.436 [conn37] distributed lock 'ci_400000000000002.customer_informations/WT-INT34:27017:1397124154:41' unlocked. 
Thu Apr 10 12:16:03.572 [conn37]    DBConfig::dropDatabase: ci_400000000000002 dropped sharded collections: 1
Thu Apr 10 12:16:03.572 [conn37]    DBConfig::dropDatabase: ci_400000000000002 dropped sharded collections: 0
Thu Apr 10 12:16:05.182 [conn37] about to log metadata event: { _id: "WT-INT34-2014-04-10T10:16:05-53466f65b5590887dff49923", server: "WT-INT34", clientAddr: "N/A", time: new Date(1397124965182), what: "dropDatabase", ns: "ci_400000000000002", details: {} }

>ceate databases "ci_400000000000001" -"ci_4000000000000010"..
>try activate sharding

Command: { "enablesharding" : "ci_400000000000002"}. Know error msg: already enabled
Command: { "shardCollection" : "ci_400000000000002.customer_informations" , "key" : { "_id" : "hashed"}}. Know error msg: already sharded

but in config.collections:

/* 2 */
{
  "_id" : "ci_400000000000002.customer_informations",
  "lastmod" : ISODate("1970-01-17T04:05:30.016Z"),
  "dropped" : true
}

We drop the databases with the java driver. but I think this isn't the problem.

Comment by Thomas Rueckstiess [ 09/Apr/14 ]

Hi Björn,

I was not able to reproduce the behavior you are describing. I've written a jstest that should execute the steps that you have given.

// create new sharding test
s = new ShardingTest( "server-13526", 2, 1);
s.stopBalancer();
var config = s.getDB('config')
 
// create databases test1 - test10, enable sharding, shard collection
for (var i = 1; i <= 10; i++) {
    db = s.getDB("test"+i)
    assert.commandWorked( db.adminCommand({enableSharding: db.getName()}) );
    assert.commandWorked( db.adminCommand({shardCollection: db.getName() + ".coll1", key: {_id: "hashed"}}) );
    db.coll1.insert({foo: 1})
}
 
// drop databases
for (var i = 1; i <= 10; i++) {
    db = s.getDB("test"+i)
    db.dropDatabase();
}
 
// create databases again, try enable sharding and shard collection
for (var i = 1; i <= 10; i++) {
    db = s.getDB("test"+i)
    assert.commandWorked( db.adminCommand({enableSharding: db.getName()}) );
    assert.commandWorked( db.adminCommand({shardCollection: db.getName() + ".coll1", key: {_id: "hashed"}}) );
    db.coll1.insert({foo: 1})
}
 
// assert data exists and collection is sharded and not dropped
for (var i = 1; i <= 10; i++) {
    db = s.getDB("test"+i)
    assert(db.coll1.count() == 1)
    assert(config.collections.count({_id: db.getName() + ".coll1"}) == 1)
    assert(config.collections.count({_id: db.getName() + ".coll1", dropped: true}) == 0)
}
 
print('\n\n EVERYTHING OK \n\n')

The script completes successfully without violating any of the assertions.

If you can successfully reproduce the problem, can you let me know what you are doing different? If you can attach your own jstest that reproduces the problem, or just give me more details for each step (i.e. shell input/output) and the log file on loglevel 2 for a successful repro run, I would appreciate it.

Thanks,
Thomas

Generated at Thu Feb 08 03:32:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.