-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Sharding
-
Sharding EMEA
-
ALL
-
Sharding 2022-03-07, Sharding NYC 2022-03-21, Sharding NYC 2022-04-04, Sharding NYC 2022-05-30, Sharding 2022-06-27, Sharding EMEA 2023-06-12
-
3
This ticket is an extension of SERVER-62272 and uses the same reproduction code. Once the sharding has been enabled for a collection that contains schema validation failures if no chunks have moved from the donor shard to a recipient shard, the recipient shard's collection info cannot be modified using collMod.
For example, given a 2 shard sharded cluster:
MongoDB Enterprise mongos> sh.status() --- Sharding Status --- sharding version: { "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("61ccb31408be338b6e44a5c0") } shards: { "_id" : "shard01", "host" : "shard01/localhost:27018,localhost:27019,localhost:27020", "state" : 1 } { "_id" : "shard02", "host" : "shard02/localhost:27021,localhost:27022,localhost:27023", "state" : 1 } active mongoses: "4.4.10" : 1 autosplit: Currently enabled: yes balancer: Currently enabled: yes Currently running: no Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: 18 : Failed with error 'aborted', from shard01 to shard02 databases: { "_id" : "config", "primary" : "config", "partitioned" : true } { "_id" : "test", "primary" : "shard01", "partitioned" : true, "version" : { "uuid" : UUID("776a14de-913b-4ed4-a1c1-6533fbbf1ab7"), "lastMod" : 1 } } test.c3 shard key: { "_id" : 1 } unique: false balancing: true chunks: shard01 17
If we issue a collMod while connected to the cluster via a mongos the primary shard will be updated, but any other shards that had this collection created via the shardCollection command will not.
For example, if we send the following command we would expect the validationLevel to be updated to off from the default of strict:
MongoDB Enterprise mongos> db.getSiblingDB("test").runCommand({ ... collMod: "c3", ... validator: { $jsonSchema: { ... bsonType: "object", ... properties: { ... i: { ... bsonType: "string", ... description: "must be a string" ... }, ... } ... } } , ... "validationLevel" : "off" ... }) { "raw" : { "shard01/localhost:27018,localhost:27019,localhost:27020" : { "ok" : 1 } }, "ok" : 1, "operationTime" : Timestamp(1640805401, 1), "$clusterTime" : { "clusterTime" : Timestamp(1640805401, 1), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } } }
If we connect to each shard individually now and run db.getCollectionInfos() the result is that shard01 in our cluster has the updated collection metadata whereas shard02 doesn't:
MongoDB Enterprise mongos> var db1 = new Mongo(db.getSiblingDB("config").shards.findOne({ _id: "shard01" }).host) MongoDB Enterprise mongos> db1.getDB("test").getCollectionInfos() [ { "name" : "c3", "type" : "collection", "options" : { "validator" : { "$jsonSchema" : { "bsonType" : "object", "properties" : { "i" : { "bsonType" : "string", "description" : "must be a string" } } } }, "validationLevel" : "off", "validationAction" : "error" }, "info" : { "readOnly" : false, "uuid" : UUID("2669f807-557f-4cb9-8d21-3ca5d1bc744f") }, "idIndex" : { "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_" } } ]
MongoDB Enterprise mongos> var db2 = new Mongo(db.getSiblingDB("config").shards.findOne({ _id: "shard02" }).host) MongoDB Enterprise mongos> db2.getDB("test").getCollectionInfos() [ { "name" : "c3", "type" : "collection", "options" : { "validator" : { "$jsonSchema" : { "bsonType" : "object", "properties" : { "i" : { "bsonType" : "string", "description" : "must be a string" } } } }, "validationLevel" : "strict", "validationAction" : "error" }, "info" : { "readOnly" : false, "uuid" : UUID("2669f807-557f-4cb9-8d21-3ca5d1bc744f") }, "idIndex" : { "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_" } } ]
- depends on
-
SERVER-71819 Broadcast collMod command to all shards
- Closed
- is duplicated by
-
SERVER-71819 Broadcast collMod command to all shards
- Closed
- is related to
-
SERVER-62294 The moveChunk cmd doesn't remove the collection entry on the local catalog after donating the last chunk
- Backlog
-
SERVER-32722 Sync collection options during moveChunk
- Closed
-
SERVER-62272 Adding schema validation to a collection can prevent chunk migrations of failing documents
- Closed
-
SERVER-44720 Send createIndexes, dropIndexes, and collMod with shard versions
- Closed
-
SERVER-45103 Sharded index commands shouldn't target primary shard if it doesn't own chunks
- Closed
-
SERVER-60694 Create DDL coordinator for collMod command
- Closed
-
SERVER-62007 Support majority read for listCollections
- Closed
- related to
-
SERVER-81033 Ignore the `collMod` response from the DBPrimary shard if it has no chunks
- Closed