-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: 4.4.0, 5.0.0, 6.0.0, 7.0.0, 8.0.0-rc0, 7.3.0, 8.1.0-rc0
-
Component/s: None
-
None
-
Catalog and Routing
-
ALL
-
CAR Team 2024-06-24, CAR Team 2024-07-08, CAR Team 2024-07-22, CAR Team 2024-08-05, CAR Team 2024-08-19, CAR Team 2024-09-02, CAR Team 2024-09-16, CAR Team 2024-09-30
-
2
Consider the following sequence:
- A client requests a dropDatabase(dbName) to a sharded cluster
- The DDL request is served by the primary shard, until the point on which all the collections under dbName get removed from the local catalog; secondary nodes replicate the collection removals;
- Before reaching the stage on which the dropDatabase op entry is written onto the oplog, the primary shard receives a shutdown (for restart) signal, so that the DDL is interrupted;
- Upon restart, the newly spawned process is elected as the RS primary
- As part of the initialisation routine, the newly spawned process fills up its DatabaseHolder (the in-memory cache of existing database names, according to the collection names retrieved from the local catalog): due to step 2, dbName is no longer present;
When the sharding DDL coordinator resumes the execution of dropDatabase(dbName), the absence of dbName from DatabaseHolder causes the function in charge of executing step 1 to early exit, skipping the instruction to generate the op entry about the completion of the DDL on the local node.
- is related to
-
SERVER-74703 Primary running dropDatabase may fail to finish database drop after replicating it due to a step down
- Closed
- related to
-
SERVER-94657 The restore role should allow dropping system.views in any database
- Closed
-
SERVER-94731 Emit change stream events for the `system.views` collection (when `showSystemEvents` is enabled)
- Closed