Problem:
printShardingStatus() prints out invalid data after a database has been removed when connecting to the mongos. e.g.

> db.printShardingStatus()
— Sharding Status —
sharding version:

{ "_id" : 1, "version" : 3 }

shards:

{ "_id" : "shard0000", "host" : "10.194.187.111:27000" } { "_id" : "shard0001", "host" : "10.116.78.81:27000" }

databases:

{ "_id" : "admin", "partitioned" : false, "primary" : "config" } { "_id" : "scaleout", "partitioned" : true, "primary" : "shard0001" }

scaleout.blogs chunks:
shard0000 1259
shard0001 1446
too many chunksn to print, use verbose if you want to force print

Other operations fail because of this stale data e.g.

moveChunk

{ "ok" : 0, "errmsg" : "that chunk is already on that shard" }

The config DB still see's the database and sharded collection

> db.databases.find()

{ "_id" : "admin", "partitioned" : false, "primary" : "config" } { "_id" : "scaleout", "partitioned" : true, "primary" : "shard0001" }

> db.chunks.find()
{ "_id" : "scaleout.blogs-ts_MinKey", "lastmod" :

{ "t" : 180000, "i" : 1 }

, "ns" : "scaleout.blogs", "min" : { "ts" :

{ $minKey : 1 }

}, "max" :

{ "ts" : -2147480140 }

, "shard" : "shard0000" }
{ "id" : "scaleout.blogs-ts-2061389163.0", "lastmod" :

{ "t" : 108000, "i" : 1920 }

, "ns" : "scaleout.blogs", "min" :

{ "ts" : -2061389163 }

, "max" :

{ "ts" : -2059556975 }

, "shard" : "shard0000" }
{ "id" : "scaleout.blogs-ts-2021389163.0", "lastmod" :

{ "t" : 179000, "i" : 0 }

, "ns" : "scaleout.blogs", "min" :

{ "ts" : -2021389163 }

, "max" :

{ "ts" : -2020322009 }

, "shard" : "shard0001" }

Reproduce:

• create a 2 shard system with a mongos
• insert data into a collection
• shard the collection
• ensure that the chunks are split between shards
• shutdown both shards
• rm /data/db/* on both shards
• startup both shards
• connect to the mongos
• issue a printShardingStatus or moveChunk

Workaround:

• bounce mongos

Business case:

• dev test / copies etc
  Simplest way to remove a data (for example in an test automation suite) would be to remove the database files. However, because of the meta data in the config DB, the same process that is used for non-sharded systems does not work on sharded systems.