dropDatabase sharding bug?

[Skipy]

Hello,

We're using mongo 1.6.5 and configured the following simple sharding
environment: 1 mongos that connects to 1 config server, with 2
shardservers with no replication.

We have 2 separate databases that are sharded on this environment:
uvdb and uvdb_2. uvdb is empty, but sharded.

When we run:

use uvdb;
db.dropDatabase()

we get the following error in console:
Mon Mar 21 14:11:19 query failed : uvdb.$cmd { dropDatabase: 1.0 }
to: 127.0.0.1
Mon Mar 21 14:11:19 Error: error doing query: failed (anon):1526
and the mongos process crashes. When we restart it, the uvdb database
does not exist (as expected, because it was dropped), but also
database uvdb_2 is empty - no data and no indexes! Also, config.chunks
is empty.

mongos log, just after dropDatabase() (and before crash):

Mon Mar 21 14:37:06 [conn292] DROP DATABASE: uvdb
Mon Mar 21 14:37:06 [conn292] DBConfig::dropDatabase: uvdb
Mon Mar 21 14:37:06 [conn292] config change: { _id:
"****IP****T14:37:06-9", server: "****IP****", time: new
Date(1300718226198), what: "dropDatabase.start", ns: "uvdb", details:
{} }
Mon Mar 21 14:37:06 [conn292] config change: { _id:
"****IP****T14:37:06-10", server: "****IP****", time: new
Date(1300718226198), what: "dropCollection.start", ns:
"uvdb.reactions_e0", details: {} }
Mon Mar 21 14:37:06 [conn292] config change: { _id:
"****IP****T14:37:06-11", server: "****IP****", time: new
Date(1300718226202), what: "dropCollection", ns: "uvdb.reactions_e0",
details: {} }
Mon Mar 21 14:37:06 [conn292] config change: { _id:
"****IP****T14:37:06-12", server: "****IP****", time: new
Date(1300718226202), what: "dropCollection.start", ns:
"uvdb_2.reactions_e2", details: {} }
Mon Mar 21 14:37:06 [conn292] config change: { _id:
"****IP****T14:37:06-13", server: "****IP****", time: new
Date(1300718226204), what: "dropCollection", ns:
"uvdb_2.reactions_e2", details: {} }
Mon Mar 21 14:37:06 [conn292] DBConfig::dropDatabase: uvdb dropped
sharded collections: 2
Mon Mar 21 14:37:06 [conn292] DBConfig::dropDatabase: uvdb dropped
sharded collections: 0
Mon Mar 21 14:37:06 [conn292] config change: { _id:
"****IP****T14:37:06-14", server: "****IP****", time: new
Date(1300718226281), what: "dropDatabase", ns: "uvdb", details: {} }
Mon Mar 21 14:37:06 [conn11595] end connection ****IP****:48975

Both shard server logs contain this:

Mon Mar 21 14:37:06 [conn229] CMD: drop uvdb.reactions_e0
Mon Mar 21 14:37:06 [conn229] CMD: drop uvdb_2.reactions_e2
Mon Mar 21 14:37:06 [conn229] wiping data for: uvdb_2.reactions_e2
Mon Mar 21 14:37:06 [conn229] dropDatabase uvdb

uname -a: Linux ****IP**** 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15
12:34:28 EST 2008 x86_64 GNU/Linux

Do you have any ideas? It looks like sending the command to drop uvdb
also issues dropping uvdb_2. The sharded collections are
uvdb.reactions_e0, and uvdb_2.reactions_e2. We have another dabatase
that is not sharded and that is intact after the mongos crash:
uvdb_1.reactions_e1.

Mihnea Giurgea
Software Engineer @ uberVU

[Skipy]

After further investigating we managed to narrow down the cause of the
problem:

It seems whenever you're calling db.dropDatabase() on a database, all
databases whose name start with that database's name will also be
deleted. So, dropping "abyx" will also cause "abyx_new" to be
dropped :).

We circumvented this by renaming our database names, but it seems like
a serious bug - maybe it was fixed in 1.8?

Thank you,
Mihnea

[Alvin Richards]

In 1.8 I get the following

> show dbs
admin (empty)
fred 0.203125GB
fred_fred 0.203125GB
local 0.203125GB
performance 0.203125GB
scaleout 3.9521484375GB
test 0.953125GB

> use fred
switched to db fred

> db.dropDatabase()
{ "dropped" : "fred", "ok" : 1 }

Which version were you using? Were you running the command connect to a mongos or mongod?

-Alvin

> --
> You received this message because you are subscribed to the Google Groups "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>

[Skipy]

I am using mongo 1.6.5, and I was connected to mongos.

[Gates]

@skipy: I have managed to reproduce this.

JIRA ticket is here, you may want to "watch" and "vote" on this item
http://jira.mongodb.org/browse/SERVER-2817

It's only happening for me in a sharded environment with sharded DBs.
Un-sharded DBs seem unaffected.

- Gates

[Skipy]

@gates: glad to hear you could reproduce it. I'll watch it on JIRA.

On Mar 23, 12:00 am, Gates <ga...@10gen.com> wrote:
> @skipy: I have managed to reproduce this.
>

> JIRA ticket is here, you may want to "watch" and "vote" on this itemhttp://jira.mongodb.org/browse/SERVER-2817