-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 7.0.0, 8.1.0-rc0, 8.0.0
-
Component/s: None
-
None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
CAR Team 2024-10-28, CAR Team 2024-11-11
-
1
In the drop collection coordinator, we drop the query analyzer entry for the collection being dropped on the config server. However, we are not attaching session information to this command and the filtering is only done by namespace. This means that in certain cases, we could end up dropping the query analyzer entry for a new incarnation of the collection.
An example of this scenario (shown in the attached repro) is:
- Start a drop coordinator and have it reach the point where it issues the drop over the query analyzer namespace
- The drop of the query analyzer entry gets stuck either in the network or on the config server
- The dbPrimary shard steps down, and a new primary steps up and issues a new drop (which succeeds)
- The drop coordinator succeeds
- Someone creates a new collection with the same namespace and enables the query analyzer
- The initial drop of the query analyzer entry completes
In this case, we would end up executing the drop after the coordinator has completed and for a completely different instance of the collection.
- is caused by
-
SERVER-70479 Make sure that dropDatabase, dropCollection and renameCollection on sharded cluster delete the config.queryAnalyzers doc for the collection being dropped or renamed
- Closed