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

[v6.0] Do not use ChunkRange::extractKeyPattern during FCV upgrade from 5.0 to 6.0

    • Catalog and Routing
    • Fully Compatible
    • ALL
    • Hide

      Start a cluster on 6.0 with FCV 5.0. Create a collection with a hashed shard key. Enable the suspendRangeDeletions failpoint on one shard. Move a chunk from that shard to some other shard. Attempt to run setFeatureCompatibilityVersion to 6.0 and it will fail saying there is no shard key index for the shard key except without the hashed value.

      Show
      Start a cluster on 6.0 with FCV 5.0. Create a collection with a hashed shard key. Enable the suspendRangeDeletions failpoint on one shard. Move a chunk from that shard to some other shard. Attempt to run setFeatureCompatibilityVersion to 6.0 and it will fail saying there is no shard key index for the shard key except without the hashed value.
    • CAR Team 2024-10-14
    • 200
    • 1

      During FCV upgrade from 5.0 to 6.0, we add the count of orphaned documents to each range deletion task. As part of this procedure, we do an index key scan of each orphaned range to get the number of documents. To do this, we are getting the shard key pattern from the range deletion task using the extractKeyPattern function.

      However, this function does not work for hashed shard keys (SERVER-71806) - it will always return a range based shard key regardless of whether the shard key is actually hashed. This will cause users upgrading from 5.0 to 6.0 with range deletion tasks for collections with hashed shard keys to fail via this assertion.

      We should not rely on the extractKeyPattern function to get the shard key for this procedure.

            Assignee:
            paolo.polato@mongodb.com Paolo Polato
            Reporter:
            allison.easton@mongodb.com Allison Easton
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: