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

Verify shard version matches before allowing createIndexes in sharding opObserver

    • Fully Compatible
    • ALL
    • v5.0
    • Sharding EMEA 2021-05-17, Sharding EMEA 2021-05-31
    • 197

      Scenario

      1. Sharded cluster. A sharded collection db.foo exists with UUID existingUuid and epoch existingOid.
      2. A createIndexes call is sent to the cluster.
      3. The first attempt at creating an index fails on the shard due to a transient error.
      4. Before the shard starts the second attempt, another thread on the same shard drops db.foo.
      5. On the second attempt, the createIndexes call will see that the collection doesn't exist, and will implicitly create db.foo, unsharded, with UUID generatedUuid.
      6. The createIndexes command will succeed, with the requested indexes on the newly created db.foo.

      This is incorrect behavior – the createIndexes call should see that the collection was dropped somehow and should fail the createIndexes call permanently.

      Proposed Solution

      Place a call to csr->checkShardVersionOrThrow() in a new function OpObserverShardingImpl::shardObserveCreateIndexes. This call will see that the newly created collection does not have epoch existingOid (because the collection is now unsharded), and will fail the operation.

      Open Questions

      1. Will failing the createIndexes call at the point of the opObserver roll back the implicit collection creation?

        1. create_indexes.diff
          2 kB
        2. bf_repro.js
          3 kB

            Assignee:
            marcos.grillo@mongodb.com Marcos José Grillo Ramirez
            Reporter:
            blake.oler@mongodb.com Blake Oler
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: