[SERVER-10295] Consider propagating dropDatabase() command to all non-primary shards in all circumstances Created: 23/Jul/13  Updated: 10/Dec/14  Resolved: 05/Aug/13

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

Type: Improvement Priority: Minor - P4
Reporter: Ian Daniel Assignee: Greg Studer
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File SERVER-10295.js    
Issue Links:
Related
is related to SERVER-10434 difficult to cleanup databases not cu... Closed
Participants:

 Description   

A "show dbs" command sent to a mongos always propagates a listDatabases command to all shards. On the other hand, a "drop database" command only propagates the dropDatabase command to non-primary shards that the mongos thinks contains sharded data (from the information in the config database).

This could be interpreted as inconsistent, and it results in an inability to drop a database from the mongos in the following scenario:

1. A sharded collection does not contain any chunks on a particular non-primary shard. Somehow, however, data is stored in a non-primary shard of a database, without it being recorded in the config database. The obvious example of this happening is if the user inserts data in the database directly in a mongod, without going via the mongos.

2. The user drops the database via the mongos.

3. The user runs the "show dbs" command from the mongos. The database that had the data stored directly in the non-primary shard is included in the list returned.

4. Subsequent attempts to drop the database via the mongos will also fail.

The attached jstest demonstrates the above scenario.

I realise that it is highly debatable whether we should actually delete the data from the non-primary shard in this case. Some users, however, have expressed surprise at the current behaviour. As such, I thought it worth raising this so that it can at least be evaluated whether to stick with the current behaviour or to change.



 Comments   
Comment by Greg Studer [ 05/Aug/13 ]

See linked issue.

Comment by Greg Studer [ 05/Aug/13 ]

Resolved as WAD - this solution would introduce scalability problems for large clusters, and the issue here is more an abstraction violation of listDatabases through mongos than a problem with dropDatabase.

The cleanup problem is real, however - and we're definitely working on / would consider further solutions to make it easier to do "garbage collection" on clusters. Ideally these would be automated.

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