[SERVER-64425] Unify shard key index logic Created: 10/Mar/22 Updated: 12/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Backlog - Cluster Scalability |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Cluster Scalability
|
| Participants: |
| Description |
|
There are currently 2 places that decides which index can be used as the shard key index. This ticket is to figure out if they can be refactored into a one place that makes these decisions. The 2 places: |
| Comments |
| Comment by Jack Mulrow [ 11/Mar/22 ] |
|
To give some more context, these two places check for slightly different things and when shardCollection/refineCollectionShardKey check for a compatible shard key index they actually run both of these. The shard_key_util.cpp logic runs a listIndexes command, which returns most of the info to know if a shard key index is valid, but notably not if a candidate index is multi key, which is only checked for by the index_catalog_impl.cpp logic, which is accessed by shardCollection/refineCollectionShardKey by running the checkShardingIndex command. So to remove one of these, we'd have to consolidate the behaviors, possibly by adding multi key info to listIndexes output or changing shard_key_util.cpp to only run checkShardingIndex. |