Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-91193

timeseriesBucketingParametersHaveChanged not properly cloned upon data migration/initial sync/restore

    • Catalog and Routing
    • Fully Compatible
    • ALL
    • v8.0, v7.3
    • CAR Team 2024-06-10, CAR Team 2024-06-24
    • 200

      Issue Status as of October 23rd 2024

      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:

      1. Only set on time-series
      2. Serialized as top-level fields (not part of the options sub-object)
      3. 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.

            Assignee:
            pierlauro.sciarelli@mongodb.com Pierlauro Sciarelli
            Reporter:
            pierlauro.sciarelli@mongodb.com Pierlauro Sciarelli
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: