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

MongoS concurrency problem with dropDatabase

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Duplicate
    • 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

        Issue Links

          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: