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

MongoS concurrency problem with dropDatabase

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Sharding
    • None
    • ALL

    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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            andrew.ryder@mongodb.com Andrew Ryder (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: