[SERVER-51755] Introduce a sharding serializer for collection DDL coordinators Created: 20/Oct/20  Updated: 10/May/22  Resolved: 28/Jan/21

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

Type: Task Priority: Major - P3
Reporter: Tommaso Tocci Assignee: Kaloian Manassiev
Resolution: Duplicate Votes: 0
Labels: PM-1965-Milestone-0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-53905 Implement PrimaryOnlyService for DDL ... Closed
Sprint: Sharding 2020-11-02, Sharding 2020-11-16, Sharding 2020-11-30, Sharding 2020-12-14, Sharding 2020-12-28, Sharding 2021-01-11, Sharding 2021-01-25, Sharding 2021-02-08
Participants:

 Description   

This new component will be built on top of the current collection critical section and will be used to prevent DDL(drop, rename, shard, etc...) operations to be executed concurrently on the same collection, when running in a sharded cluster.

Each DDL operation needs to enter the DDL critical section before to start and will release it on its cleanup. If a DDL operation tries to enter a critical section already occupied by another DDL operation, an exception will be thrown and will be propagated to the router.

This component will be exposed by the CollectionShardingRuntime and will expose two main functions:

  • Enter DDL critical section (may throw exception)
  • Exit DDL critical section


 Comments   
Comment by Tommaso Tocci [ 20/Oct/20 ]

For sure we need to enter this critical section when we try to shard an unsharded collection, so that we won't run two shardCollection at the same time on the same collection.
Moreover having in mind that all collections will be made soon sharded by default by PM-1967 , I think the short answer is yes: The DDL serializer will be used for both sharded and unsharded collections inĀ  sharded clusters.

Comment by Louis Williams [ 20/Oct/20 ]

Does this only apply to sharded collections or all collections?

Generated at Thu Feb 08 05:26:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.