[SERVER-42008] Simultaneous sharded collection drops do not have a total ordering in change streams Created: 28/Jun/19  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Bernard Gorman Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: change-streams-improvements
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-34554 Database drops do not have a total or... Backlog
Assigned Teams:
Query Execution
Participants:

 Description   

At present, when dropping a sharded collection, the drop command is dispatched sequentially to each shard. This means that each successive drop always has a higher clusterTime than its predecessor, such that the drop events appear in a change stream with a specific ordering.

However, this ordering is due purely to current sharding mechanics and is not reflected in the resume token format. If a sharded collection were to be dropped on two or more shards at the same clusterTime - as might happen if the sharding team decides to parallelize the collection drop operation - then the events on each shard would produce identical resume tokens, since they all have the same UUID and no documentKey. This would lead to exactly the same ordering fiasco as described in SERVER-34554, and for the same reasons.

If and when we decide to update the resume token format to address SERVER-34554, we should make sure to address this potential future problem as well.


Generated at Thu Feb 08 04:59:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.