[SERVER-15213] MongoS concurrency problem with dropDatabase Created: 11/Sep/14  Updated: 05/Dec/19  Resolved: 11/Sep/14

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

Type: Bug Priority: Major - P3
Reporter: Andrew Ryder (Inactive) Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-939 Ability to distribute collections in ... Blocked
Related
is related to SERVER-4232 `show collections` on mongos doesn't ... Closed
Operating System: ALL
Participants:
Case:

 Description   

When an unsharded database is re-created after a "dropDatabase" command has been used, and it happens to be located on a different shard as a result, only the initiating mongos of the drop observes the subsequent re-creation - all others continue to route as they did before.

This leads to the same problems observed with movePrimary, other mongos will populate & query, what is now, the wrong shard.

This is essentially a different way to invoke the movePrimary command, with similar results, and thus requires that all other mongos be restarted or flushed to function correctly.

This seems like an unreasonable requirement for dropDatabase to be burdened with, given it is considerably more common than movePrimary.



 Comments   
Comment by Andrew Ryder (Inactive) [ 17/Aug/16 ]

Hi Jason!

Greg is not available but I can attempt to address your concerns in his place.

We broadly agree with your definition of unsharded database. We can work with that nomenclature.

To your other point:

> The workarounds include ... sharding collections on creation but disabling balancing per-collection.
Greg, are you saying that if one were to shard all collections on a database, then invoke dropDatabase, that one would not need to flush the mongos config, that somehow because all of the collections were sharded that the dropDatabase operation gets tracked by all the mongos instances with references to that database?

Yes. But be aware the workaround only applies if you shard every collection on creation (and optionally disable balancing to prevent any migration) before and after the dropDatabase operation (or movePrimary). This works because sharded collections are versioned, where-as nothing else is. The fundamental issue with unsharded collections is that there is no version number by which a MongoS can detect that something has changed.

I hope this helps.

Kind regards,
Andrew

Comment by Jason R. Coombs [ 06/Aug/16 ]

> There's no concept really of an "unsharded database"

I would say that any database for which `enableSharding` has not been invoked would be an unsharded database. I might also include any database which has no sharded collections.

> The workarounds include ... sharding collections on creation but disabling balancing per-collection.

Greg, are you saying that if one were to shard all collections on a database, then invoke dropDatabase, that one would not need to flush the mongos config, that somehow because all of the collections were sharded that the dropDatabase operation gets tracked by all the mongos instances with references to that database?

Comment by Greg Studer [ 11/Sep/14 ]

> When an unsharded database is re-created after a "dropDatabase" command has been used
There's no concept really of an "unsharded database", but this definitely occurs with unsharded collections in that database. The "enableSharding" flag just allows sharded collections to be created - it may go away in the future.

The core issue is that unsharded collections need to be versioned and currently any movement, implicit or explicit, of an unsharded collection between shards is not tracked. This issue is SERVER-939.

The workarounds include app-enforced downtime for these collections and explicitly flushing mongos config (flushRouterConfig) after operations of this type, or sharding collections on creation but disabling balancing per-collection.

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