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

MongoS concurrency problem with dropDatabase

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Sharding
    • Labels:
      None
    • Operating System:
      ALL
    • 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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              andrew.ryder Andrew Ryder
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: