[SERVER-85372] Make cloneCollectionAsCapped and convertToCapped work properly in case of concurrent DDLs Created: 18/Jan/24  Updated: 06/Feb/24

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Pierlauro Sciarelli Assignee: Pierlauro Sciarelli
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-84482 convertToCapped and cloneCollectionAs... Blocked
is depended on by SERVER-85435 Remove check for sharding in cloneCol... Backlog
Duplicate
is duplicated by SERVER-85917 covertToCapped and cloneToCapped comm... Closed
Related
related to SERVER-86030 Temporarly disable convertToCapped an... Open
Assigned Teams:
Catalog and Routing
Operating System: ALL
Participants:

 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.


Generated at Thu Feb 08 06:57:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.