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

Recreation of same database with different cases could lead to database unavailability

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Gone away
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Sharding EMEA
    • ALL
    • Hide
      1. Create a database with lower case "mydb"
      2. Start a dropDatabase("mydb")
      3. The primary shard will forward the dropDatabaseParticipantCmd to all shards.
      4. Each participant shard will drop the database locally.
      5. Before the drop database coordinator have removed the database entry from the config server, one of the participant shard manage to refresh the database, thus it will re-create the database entry for "mydb" in the local catalog.
      6. The drop  database coordinator deletes "mydb" entry from the config server and will call
      7. The drop database coordinator forwards the flushDatabaseCacheUpdates command to all the participants .
      8. The participant call DatabaseHolder::clearDbInfo("mydb"), that will clear the sharding metadata associated to the database but will leave the database registered in the sharding catalog.
      9. A new database "MYDB" is created on the config sever.
      10. Next time the participant shard will perform a refresh for this new database "MYDB", it will try to create a new entry in the local catalog and it will fail with DatabaseDifferCase error because in the local catalog there is still registered the database "mydb" created at step 5
      Show
      Create a database with lower case "mydb" Start a dropDatabase("mydb") The primary shard will forward the dropDatabaseParticipantCmd to all shards . Each participant shard will drop the database locally. Before the drop database coordinator have removed the database entry from the config server, one of the participant shard manage to refresh the database, thus it will re-create the database entry for "mydb" in the local catalog . The drop  database coordinator deletes "mydb" entry from the config server and will call The drop database coordinator forwards the flushDatabaseCacheUpdates command to all the participants . The participant call DatabaseHolder::clearDbInfo("mydb") , that will clear the sharding metadata associated to the database but will leave the database registered in the sharding catalog. A new database "MYDB" is created on the config sever. Next time the participant shard will perform a refresh for this new database "MYDB", it will try to create a new entry in the local catalog and it will fail with DatabaseDifferCase error because in the local catalog there is still registered the database "mydb" created at step 5

      If two databases with same name but different cases (e.g.: DB1, db1) are dropped and created concurrently some shards could end up with inconsistent in-memory metadata causing database unavailability until the affected node is restarted.

            Assignee:
            backlog-server-sharding-emea [DO NOT USE] Backlog - Sharding EMEA
            Reporter:
            tommaso.tocci@mongodb.com Tommaso Tocci
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: