-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
ALL
Disclaimer: the command is not currently exposed on the router and can only be directly called on shards. Once SERVER-80416 will expose cloneCollectionAsCapped, the problem will surface.
The cloneCollectionAsCapped command is currently unsafe because is does not properly serialize with concurrent DDLs on the same namespace and will be even more unsafe "tomorrow" (once unsharded collections will be tracked) because it only performs changes on the local catalog.
Purpose of this ticket is to fix such limitation. The new implementation could perform an aggregation to copy the documents and create the new capped collection. More details in this comment.
- duplicates
-
SERVER-80416 Expose cloneCollectionAsCapped command via mongos
- Backlog
- is depended on by
-
SERVER-84482 cloneCollectionAsCapped must support unsplittable collections
- Closed
-
SERVER-85435 Remove check for sharding in cloneCollectionAsCapped tests
- Closed
- is duplicated by
-
SERVER-85917 covertToCapped and cloneToCapped commads do not serialize properly with other DDL operations in sharded cluster
- Closed
- related to
-
SERVER-86030 Temporarly disable convertToCapped and cloneToCapped in test fuzzer when running against sharded clusters
- Closed