[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 SERVER-63437 is completed, we will be logging the shardCollection no-op oplog entry during resharding operation. But the spec currently only includes the shardCollection and shardKey fields. We should log the full shardCollection command spec so that it's consistent with the user requested shardCollection operation. We currently do not have access to the other parameters on the recipient shard. We need this information propagated from the config server.



 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:

The ReshardingCoordinator constructs it and would have access to the values to fill in

I think you'd also need to add the same optional members to https://github.com/mongodb/mongo/blob/e97e4ff09cdb2398b571683312b2ddf92694a025/src/mongo/s/resharding/type_collection_fields.idl#L84 which is the actual struct shards parse from the coordinator

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 SERVER-63437, is to log a system-only reshardCollectionBegin event at the start of the resharding operation that includes all details of the reshardCollection command. At present there is no good place to do this; we need to include the reshardingUUID in the event, but no shard-based component knows all the details of the original command PLUS the resharding UUID until after the operation completes.

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