[SERVER-72879] Recreation of same database with different cases could lead to database unavailability Created: 16/Jan/23  Updated: 27/Oct/23  Resolved: 25/Jan/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Tommaso Tocci Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-72869 Push the database metadata from the S... Closed
is depended on by SERVER-71368 Stop excluding tests that drop collec... Closed
Problem/Incident
is caused by SERVER-64209 Push the DatabaseShardingState state ... Closed
Assigned Teams:
Sharding EMEA
Operating System: ALL
Steps To Reproduce:
  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
Participants:

 Description   

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.



 Comments   
Comment by Tommaso Tocci [ 25/Jan/23 ]

Fixed by   SERVER-72869

Generated at Thu Feb 08 06:23:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.