Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
None
-
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
Description
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.
Attachments
Issue Links
- 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
-
- Backlog
-
- is related to
-
SERVER-77307 Denylist schema_validator_with_expr_variables.js from concurrency suites with balancer
-
- Closed
-