Details
-
Bug
-
Resolution: Unresolved
-
Major - P3
-
None
-
None
-
None
-
None
-
Catalog and Routing
-
ALL
Description
The cloneCollectionAsCapped and convertToCapped commands are currently only exposed by replica sets (or shards) and SERVER-84091/SERVER-84482 are going to make them available on the router starting from v7.3. The implementation under those tickets will simply forward the request from the router to the primary shard for the targeted db.
This is unsafe because both commands do not properly serialize with concurrent DDLs on the same namespace(s) and will be even more unsafe "tomorrow" (once unsharded collections will be tracked) because they are only creating the collection on the local catalog.
Purpose of this ticket is to fix such limitation starting from v8.0. The new implementation could perform an aggregation to copy the documents and create the new capped collection. More details in this comment.
Attachments
Issue Links
- is depended on by
-
SERVER-84482 convertToCapped and cloneCollectionAsCapped commands should support unsplittable tracked collections
-
- Blocked
-
-
SERVER-85435 Remove check for sharding in cloneCollectionAsCapped tests
-
- Backlog
-
- 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
-
- Open
-