-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 7.0.0, 7.3.0-rc0, 7.2.0
-
Component/s: None
-
None
-
Query Integration
-
Fully Compatible
-
v7.2, v7.0
-
QI 2023-06-26, QI 2023-07-10, QI 2023-07-24, QI 2023-08-07, QI 2023-08-21, QI 2023-09-04, QI 2023-09-18, QI 2023-10-02, QI 2023-10-16, QI 2023-10-30, QI 2023-11-13, QI 2023-11-27, QI 2023-12-11, QI 2023-12-25, QI 2024-01-08, QI 2024-01-22
If you create a sharded time-series collection using the shardCollection command that has a shardKey {timeField: 1} the resulting index in the buckets collection will have the key { control.min.time: 1.0 }.
However, calling the createIndex command on a sharded time-series collection with the same key {timeField: 1} results in an index in the buckets collection with the key { control.min.time: 1.0, control.max.time: 1.0 }.
These two indexes have the same key for the view backing the buckets collection.
We should investigate if these two commands should produce indexes with the same keys for the buckets collection. Here is a file to reproduce this SERVER-77112.js
- is depended on by
-
COMPASS-7579 Investigate changes in SERVER-77112: shardCollection and createIndex create different indexes on time-series buckets collections
- Closed
- is related to
-
SERVER-84682 Create a new version of refineCollectionShardKey to ensure consistent shard key index creation across FCV transitions
- Closed
- related to
-
SERVER-84180 refineCollectionShardKey does not rewrite the new shard key for time-series collections
- Backlog
-
SERVER-85243 Add FCV upgrade/downgrade test for shardCollection creating the updated buckets index on the timeField
- Blocked
-
SERVER-84741 Ensure the shard key is rewritten for the buckets collection when calling validateShardKeyIndexExistsOrCreateIfPossible
- Closed