-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 7.0.0, 7.3.0-rc0, 8.0.0-rc0
-
Component/s: None
-
None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
CAR Team 2024-06-10, 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, CAR Team 2024-10-14, CAR Team 2024-10-28
-
3
Currently, to handle drop of timeseries, dropCollection starts with a rename of a buckets collection to the view namespace. This rename assumes that there can't be a buckets namespace co-existing with a collection (not a view) in the namespace of the view.
However, in some situations this can turn out not to be true. In $out to timeseries, the stage creates the target collection in two steps: first rename of the temporary collection to the buckets namespace, then creation of the view. These two steps can interleave with createCollection (or createView) to the timeseries namespace, which breaks the assumption of dropCollection. If that happens, $out will fail when trying to create the view, and during cleanup, it will leave the broken buckets collection (current version, note that the drop is conditional to not having anything in the target namespace) or blindly drop it (previous versions).
In these circumstances, when the user (or $out) tries to drop the broken buckets collection, dropCollection will reach this point, see that there is a collection in the namespace to drop, and proceed to drop the collection, which technically is a data loss, ironically leaving the buckets collection (which was requested to be dropped in the first place) untouched.
- is related to
-
SERVER-82085 Race condition between $out to timeseries and shard collection
- Closed
- related to
-
SERVER-95760 $out: acquire locks for target namespaces when outputting to timeseries
- Blocked