-
Type: Bug
-
Resolution: Fixed
-
Priority: Critical - P2
-
Affects Version/s: 7.3.2, 8.0.0-rc7
-
Component/s: None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
v8.0, v7.3
-
CAR Team 2024-06-10, CAR Team 2024-06-24
-
200
ISSUE DESCRIPTION AND IMPACT
When cloning a Time Series collection, the internal timeseriesBucketingParametersHaveChanged flag is defaulted to false. If the user has ever changed bucketing granularity via collMod before cloning a collection, some queries may be missing matching documents.
All cloning procedures are incorrectly setting the timeseriesBucketingParametersHaveChanged flag: initial synchronization, chunk migration, movePrimary, resharding, mongodump/ mongorestore and others.
DIAGNOSIS
The issue only affects users who changed bucketing granularity via collMod for a Time Series collection that was later cloned.
AFFECTED VERSIONS
The range of affected versions is v7.1.0 - v7.3.3.
REMEDIATION AND WORKAROUNDS
The issue has been fixed in v8.0.0. Since this issue only impacts clusters on rapid releases, all impacted clusters have been upgraded to 8.0.0 and no further remediation is required.
(This issue is similar to SERVER-91194 that has the same root cause.)
Original description
The timeseriesBucketingParametersHaveChanged collection option is:
- Only set on time-series
- Serialized as top-level fields (not part of the options sub-object)
- Defaulted to false at bucket collection creation time
Defaulting timeseriesBucketingParametersHaveChanged to false (bullet 3) is problematic because collections are not only created from scratch but may also be created due to data cloning in the following cases:
- Initial synchronization - when cloning a collection as part of adding a new node to a replica set
- Chunk migration - when cloning a collection as part of migrating sharded collection's data
- MovePrimary - when cloning a collection as part of changing its db primary in a sharded cluster
- Resharding (and moveCollection) - when cloning a collection as part of redistributing all its data
- Mongodump/ mongorestore: when restoring a cluster from a backup
This means that in all clusters starting from v7.1 (SERVER-76258), the value of timeseriesBucketingParametersHaveChanged may be incorrect, leading to incorrect query results (reproducible attached - thanks gil.alon@mongodb.com for providing the sequence of inserts to hit the issue).
The short term solution is to always pretend the option is set to true (not changing the actual value on the catalog but always behave as if it was).
SERVER-91195 will take care of designing a long-term solution for avoiding hitting the issue in the future.
- causes
-
SERVER-91411 Check for timeseries options in timeseriesBucketingParametersHaveChanged
- Closed
- has to be done before
-
SERVER-91231 Get rid of md.timeseriesBucketingParametersHaveChanged for avoiding confusion/misuses
- Backlog
- is caused by
-
SERVER-76258 Flag when time-series granularity isn't modified after collection creation
- Closed
- is depended on by
-
SERVER-91231 Get rid of md.timeseriesBucketingParametersHaveChanged for avoiding confusion/misuses
- Backlog
- is related to
-
SERVER-91610 Do not execute TSBucketingParametersUnchanged feature flag check on secondaries performing oplog application
- Open
-
SERVER-91195 Provide a generic backportable solution not to miss top-level timeseries collection options
- Closed
- related to
-
SERVER-91367 Complete TODO listed in SERVER-91193
- Closed
-
SERVER-91754 Add a check to validation to check for changed bucketing parameters for time-series
- Closed
-
SERVER-91624 Detect mixed schema buckets in time series collection validation
- Closed