[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: |
|
||||||||
| 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:
|
| 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. |
| Comment by Louis Williams [ 20/Oct/20 ] |
|
Does this only apply to sharded collections or all collections? |