[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: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| 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:
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, |
| 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 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. |