[SERVER-69874] Document or possibly mitigate scenario where shards end up with different prepareUnique and unique index settings Created: 21/Sep/22  Updated: 29/Oct/23  Resolved: 08/Nov/22

Status: Closed
Project: Core Server
Component/s: Catalog, Sharding
Affects Version/s: None
Fix Version/s: 6.1.1, 6.0.4, 6.2.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Yuhong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
is related to SERVER-69429 Missing checks in collMod for shard k... Closed
is related to SERVER-61158 Convert a non-unique index to a uniqu... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v6.1, v6.0
Sprint: Execution Team 2022-10-17, Execution Team 2022-10-31, Execution Team 2022-11-14
Participants:

 Description   

This isn't a new inconsistency for indexes on a sharded collection but a new way for an inconsistency to manifest. For comparison, the createIndexes command broadcasted by mongos to all shards which own a chunk for the sharded collection can fail on one shard and succeed on another (same for the dropIndexes command). The main consequence is it can lead to chunk migrations failing with a DuplicateKey exception because shards are enforcing different index constraints from each other.

Let's say there is a collection sharded on {x: 1} which lives on 2 shards and has a non-unique index {x: 1, y: 1}.

  1. The collMod command is run with {prepareUnique: true} for the {x: 1, y: 1} index to start preventing new duplicate (x, y) pairs from being inserted or updated. This step succeeds on both shards.
  2. The collMod command is run with {unique: true} for the {x: 1, y: 1} index to verify there are no existing duplicate (x, y) pairs. This step succeeds on one of the shards and fails on the other shard.

A chunk migration between the 2 shards may fail with a DuplicateKey error due to the (x, y) pairs not being globally unique across all shards. Removing the duplicates and retrying the collMod command is run with {unique: true} may not be practical. However the cluster operator is also left without a means of converting the {x: 1, y: 1} index back to being a non-unique index.



 Comments   
Comment by Githook User [ 21/Nov/22 ]

Author:

{'name': 'Yuhong Zhang', 'email': 'yuhong.zhang@mongodb.com', 'username': 'YuhongZhang98'}

Message: SERVER-69874 Execute in dryRun mode first during unique index conversion on a sharded collection to ensure consistent index specs across shards

(cherry picked from commit 78131d8e3da7114a037d55add0483a82a5133bd8)
(cherry picked from commit b3268a6f0b1479366ccd41418267db1b556c0e86)
Branch: v6.0
https://github.com/mongodb/mongo/commit/55764dfbc05f6cc45e210e8f65a6c40a34d0c9ff

Comment by Githook User [ 18/Nov/22 ]

Author:

{'name': 'Yuhong Zhang', 'email': 'yuhong.zhang@mongodb.com', 'username': 'YuhongZhang98'}

Message: SERVER-69874 Execute in dryRun mode first during unique index conversion on a sharded collection to ensure consistent index specs across shards

(cherry picked from commit 78131d8e3da7114a037d55add0483a82a5133bd8)
Branch: v6.1
https://github.com/mongodb/mongo/commit/b3268a6f0b1479366ccd41418267db1b556c0e86

Comment by Githook User [ 09/Nov/22 ]

Author:

{'name': 'Yuhong Zhang', 'email': 'yuhong.zhang@mongodb.com', 'username': 'YuhongZhang98'}

Message: SERVER-69874 Fix collMod unit tests
Branch: master
https://github.com/mongodb/mongo/commit/2cbd6f178c05c706e820ce62418a3e38a1e26f4a

Comment by Githook User [ 08/Nov/22 ]

Author:

{'name': 'Yuhong Zhang', 'email': 'yuhong.zhang@mongodb.com', 'username': 'YuhongZhang98'}

Message: SERVER-69874 Execute in dryRun mode first during unique index conversion on a sharded collection to ensure consistent index specs across shards
Branch: master
https://github.com/mongodb/mongo/commit/78131d8e3da7114a037d55add0483a82a5133bd8

Generated at Thu Feb 08 06:14:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.