Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-10295

Consider propagating dropDatabase() command to all non-primary shards in all circumstances

    • Type: Icon: Improvement Improvement
    • Resolution: Done
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • Labels:
      None

      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.

            Assignee:
            greg_10gen Greg Studer
            Reporter:
            jantje.daniel Ian Daniel
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: