[SERVER-58606] Investigate concurrent shardCollection and zone modification behaviour Created: 16/Jul/21 Updated: 27/Oct/23 Resolved: 16/Jul/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 5.0.0 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Tommaso Tocci | Assignee: | Marcos José Grillo Ramirez |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Sprint: | Sharding EMEA 2021-08-09 | ||||
| Participants: | |||||
| Description |
|
The old shardCollection command (the one that was running on the configsvr) was locking the zones while performing the shard collection, I think we accidentally removed this syncronization in the new create collection coordinator. |
| Comments |
| Comment by Marcos José Grillo Ramirez [ 16/Jul/21 ] |
|
It is not a problem having a concurrent zone change while sharding a collection, the balancer ensures eventual consistency, also, the new behavior could be consider as analogous to the scenario of having the shard collection taking the lock first and having the zone changes committed after the shard collection concludes. |