Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-71819

Broadcast collMod command to all shards

    • 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.

            Assignee:
            pol.pinol@mongodb.com Pol Pinol
            Reporter:
            vishnu.kaushik@mongodb.com Vishnu Kaushik
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: