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

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

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • 3.3.2
    • 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()));

    Description

      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.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated: