-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Sharding EMEA
-
Minor Change
-
ALL
-
v7.1, v7.0, v6.0
-
Sharding EMEA 2023-05-29, Sharding EMEA 2023-06-12, Sharding EMEA 2023-06-26, Sharding EMEA 2023-07-10, Sharding EMEA 2023-07-24, Sharding EMEA 2023-08-07, Sharding EMEA 2023-09-04, Sharding EMEA 2023-09-18
-
0
-
3
When we run collMod on a collection in a sharded cluster, the CollModCoordinator runs collMod only on shards that own a chunk. This makes it possible to bypass the effects of collMod under certain conditions.
For example, let's take a two shard set up, only one node in each shard and in the config server. Shard shard-rs0 is the primary shard for the collection we use below. Run the following commands on mongos:
// Create and shard collection. db.apple.insert({a: 1}) sh.shardCollection('test.apple', {_id: 1}) // Disable the balancer so we can get the chunks to stay where we want them sh.disableBalancing('test.apple') // Let's have two chunks, and I'm going to move both to non-primary shard 'shard-rs1'. sh.splitAt('test.apple', {_id: 0}) sh.moveChunk('test.apple', {_id: 1}, 'shard-rs1') sh.moveChunk('test.apple', {_id: -1}, 'shard-rs1') // Turn on schema validation - we see that "collMod" only runs on non-primary 'shard-rs1', because it owns all the // chunks. db.runCommand({collMod: "apple", validator: {$jsonSchema: {properties: {a: {bsonType: "int"}}}}}) // This doesn't reflect the collMod. My guess is this is because mongos talks to the primary shard // which never ran collMod. db.getCollectionInfos() // Schema validation complains, as it should (query runs on non-primary shard): db.apple.insert({_id: 0, a: "hello"}) // Move a chunk back to primary shard. sh.moveChunk('test.apple', {_id: 1}, 'shard-rs0') // Validation complains, because it is routed to 'shard-rs1': db.apple.insert({_id: -2, a: "hello"}) // Doesn't complain and insert works, because it is routed to 'shard-rs0': db.apple.insert({_id: 2, a: "hello"})
In the above example the final statement bypassed the schema validation, which shouldn't happen.
I have not investigated how other collMod behaviors (such as to convert indexes to unique) are affected and if other DDL coordinators have the same problem.
- causes
-
SERVER-81033 Ignore the `collMod` response from the DBPrimary shard if it has no chunks
- Closed
- depends on
-
SERVER-78524 async_rpc util getAllResponsesOrFirstErrorWithCancellation can leave dangling continuations
- Closed
- duplicates
-
SERVER-62310 collMod command not sent to all shards for a sharded collection if no chunks have been received
- Closed
- is depended on by
-
SERVER-62310 collMod command not sent to all shards for a sharded collection if no chunks have been received
- Closed
-
SERVER-75653 Add check for validator rules on checkMetadataConsistency
- Closed
- is related to
-
SERVER-77307 Denylist schema_validator_with_expr_variables.js from concurrency suites with balancer
- Closed
-
SERVER-90117 Interrupting collMod can leave behind inconsistent collection options
- Closed