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

Server crash when reading from sharded collections with user-created '<db>.system.buckets.<coll>' collection

    XMLWordPrintableJSON

Details

    • Fully Compatible
    • ALL
    • Hide

      sh.shardCollection('test.foo', {x:1})
      db.system.buckets.foo.insert({a: 1})
      db.foo.find()
      

      Show
      sh.shardCollection('test.foo', {x:1}) db.system.buckets.foo.insert({a: 1}) db.foo.find()
    • QE 2022-11-28, QE 2022-12-12, QE 2022-12-26, QE 2023-01-09, QE 2023-01-23, Sharding EMEA 2022-10-31
    • 105

    Description

      Users should never create collections with the 'system.buckets' prefix. However, today nothing prevents it (SERVER-61589)

      On a non time-series sharded collection <dbName>.<collName>, if the user manually creates the <db>system.buckets.<collName> collection, reads on the sharded collections will crash the server. This is because this logic will choose the bucket namespace to install on the OperationShardingState alongside the attached shardVersion. Then, when calling getOwnershipFilter, the namespace <db>.<collName> won't be found on the OperationShardingState and and invariant will be tripped.

      One possible fix is to prevent users from creating the buckets collection (SERVER-61589). This tickets is to decide whether to go with that solution, or fix it in some different way.

      Edit: This ticket is to fix the nss rewrite done on service_entry_point so that looks at the TimeseriesOptions to confirm whether it is really a timeseries collection.

      Attachments

        Activity

          People

            rushan.chen@mongodb.com Rushan Chen
            jordi.serra-torrens@mongodb.com Jordi Serra Torrens
            Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: