-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
ALL
-
v5.0
-
Sharding EMEA 2021-05-17, Sharding EMEA 2021-05-31
-
197
Scenario
- Sharded cluster. A sharded collection db.foo exists with UUID existingUuid and epoch existingOid.
- A createIndexes call is sent to the cluster.
- The first attempt at creating an index fails on the shard due to a transient error.
- Before the shard starts the second attempt, another thread on the same shard drops db.foo.
- 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.
- 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
- Will failing the createIndexes call at the point of the opObserver roll back the implicit collection creation?
- causes
-
SERVER-57180 concurrent_create_indexes_with_drop_and_create_sharded_collection.js is missing requires_persistence tag
- Closed
- is related to
-
SERVER-56774 [Resharding] Clear filtering metadata after dropping the original collection on donor shards post-commit
- Closed
- related to
-
SERVER-55879 Accommodate implicit collection creation in ReshardingTest's post-state assertions
- Closed