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

mongos has inconsistent behavior for replacement-style single-update with empty query

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 3.3.2
    • Component/s: Sharding
    • Cluster Scalability
    • ALL
    • Hide
      var st = new ShardingTest({shards: 2, mongos: 1, other: { noAutoSplit: ""}}); var dbName = 'test';
      var collNS = dbName + '.foo';
      var numShardKeys = 3;
      
      // Enable sharding.
      assert.commandWorked(st.s.adminCommand({ enableSharding: dbName }));
      st.ensurePrimaryShard(dbName, st._shardNames[0]);
      assert.commandWorked(st.s.adminCommand({ shardCollection: collNS, key: { x: 1 }}));
      
      // Insert some documents.
      for (var i=0; i<numShardKeys; i++) {
          assert.writeOK(st.s.getCollection(collNS).insert({ x: i }));
      }
      
      jsTest.log("All documents before update\n" + tojson(st.s.getCollection(collNS).find().toArray()));
      
      // updating x:0 will succeed, x:2 will fail, because x:0 is the first document encountered by mongod.
      //jsTest.log("Update result\n" + st.s.getCollection(collNS).update({}, { x: 0, fieldToUpdate : 1 }));
      jsTest.log("Update result\n" + st.s.getCollection(collNS).update({}, { x: 2, fieldToUpdate : 1 }));
      
      jsTest.log("Find() after update returned\n" + tojson(st.s.getCollection(collNS).find().toArray()));
      
      Show
      var st = new ShardingTest({shards: 2, mongos: 1, other: { noAutoSplit: ""}}); var dbName = 'test' ; var collNS = dbName + '.foo' ; var numShardKeys = 3; // Enable sharding. assert .commandWorked(st.s.adminCommand({ enableSharding: dbName })); st.ensurePrimaryShard(dbName, st._shardNames[0]); assert .commandWorked(st.s.adminCommand({ shardCollection: collNS, key: { x: 1 }})); // Insert some documents. for ( var i=0; i<numShardKeys; i++) { assert .writeOK(st.s.getCollection(collNS).insert({ x: i })); } jsTest.log( "All documents before update\n" + tojson(st.s.getCollection(collNS).find().toArray())); // updating x:0 will succeed, x:2 will fail, because x:0 is the first document encountered by mongod. //jsTest.log( "Update result\n" + st.s.getCollection(collNS).update({}, { x: 0, fieldToUpdate : 1 })); jsTest.log( "Update result\n" + st.s.getCollection(collNS).update({}, { x: 2, fieldToUpdate : 1 })); jsTest.log( "Find() after update returned\n" + tojson(st.s.getCollection(collNS).find().toArray()));

      Mongos allows a replacement-style single-update with an empty query but an update containing the shard key to be executed on the shards.

      If the first document the update encountered by mongod contains the shard key, the update will be executed successfully.

      Otherwise, the mongod will return the following write error to mongos, which is passed to the client:

      [js_test:test] 2016-02-29T11:52:11.314-0500 assert: write failed with error: {
      [js_test:test] 2016-02-29T11:52:11.314-0500 	"nMatched" : 0,
      [js_test:test] 2016-02-29T11:52:11.314-0500 	"nUpserted" : 0,
      [js_test:test] 2016-02-29T11:52:11.315-0500 	"nModified" : 0,
      [js_test:test] 2016-02-29T11:52:11.315-0500 	"writeError" : {
      [js_test:test] 2016-02-29T11:52:11.315-0500 		"code" : 66,
      [js_test:test] 2016-02-29T11:52:11.315-0500 		"errmsg" : "After applying the update to the document {x: 5.0 , ...}, the (immutable) field 'x' was found to have been altered to x: 0.0"
      [js_test:test] 2016-02-29T11:52:11.315-0500 	}
      [js_test:test] 2016-02-29T11:52:11.315-0500 }
      [js_test:test] 2016-02-29T11:52:11.315-0500 _getErrorWithCode@src/mongo/shell/utils.js:23:13
      [js_test:test] 2016-02-29T11:52:11.315-0500 doassert@src/mongo/shell/assert.js:13:14
      [js_test:test] 2016-02-29T11:52:11.315-0500 assert.writeOK@src/mongo/shell/assert.js:388:9
      [js_test:test] 2016-02-29T11:52:11.315-0500 @test.js:31:1
      

      Therefore, the behavior of the update on a mongos depends on the order of documents seen by the mongod.

            Assignee:
            backlog-server-cluster-scalability [DO NOT USE] Backlog - Cluster Scalability
            Reporter:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: