[SERVER-66671] Log full 'shardCollection' operation spec in the oplog during reshardCollection operation Created: 23/May/22 Updated: 12/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Arun Banala | Assignee: | Backlog - Cluster Scalability |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | cs-subteam1, sharding-nyc-subteam1 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Cluster Scalability
|
| Participants: | |
| Story Points: | 2 |
| Description |
|
After |
| Comments |
| Comment by Max Hirschhorn [ 09/Jun/22 ] |
|
Copying my Slack messages about the work involved to have the shards be aware of the numInitialChunks and collation command parameters:
Another option for this ticket is to wait until the ReshardingCoordinator (runs on config server primary) has been moved and unified into the ReshardCollectionCoordinator (runs on primary of the primary shard for database) where the primary shard would have access to the full reshardCollection command and the reshardingUUID because it would be generating the latter itself. |
| Comment by Bernard Gorman [ 25/May/22 ] |
|
This may become an issue in the future; the only reason it's OK at the moment is that all shardCollection-related fields specified in the reshardCollection command, aside from the shard key itself, must either be default-valued or are not relevant for C2C. Another option proposed by max.hirschhorn@mongodb.com, which seems preferable to the artificial shardCollection event added in |