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

setFCV on config server should only generate UUIDs for non-dropped sharded collections

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.6.0-rc2
    • Fix Version/s: 3.6.1, 3.7.1
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v3.6
    • Steps To Reproduce:
      Hide

      (function() {
          "use strict";
       
          load('jstests/libs/parallelTester.js');
       
          const dbName = "test";
          const collName = "foo";
          const ns = dbName + "." + collName;
       
          const st = new ShardingTest({mongos: 1, config: 1, shards: 2, rs: {nodes: 1}});
       
          assert.commandWorked(st.s.adminCommand({enableSharding: dbName}));
          assert.commandWorked(st.s.adminCommand({shardCollection: ns, key: {x: 1}}));
       
          let collEntryBefore = st.s.getDB("config").getCollection("collections").find({ _id: ns }).toArray()[0];
          print("collEntryBefore: " + tojson(collEntryBefore));
          assert.neq(null, collEntryBefore.uuid);
       
          jsTest.log("dropping collection " + ns);
          assert.commandWorked(st.s.getDB(dbName).runCommand({ drop: collName }));
       
          let collEntryAfter = st.s.getDB("config").getCollection("collections").find({ _id: ns }).toArray()[0];
          print("collEntryAfter: " + tojson(collEntryAfter));
          // Expect this assert to fail, which demonstrates the bug.
          assert.neq(null, collEntryAfter.uuid);
       
          st.stop();
      })();
      

      Show
      (function() { "use strict";   load('jstests/libs/parallelTester.js');   const dbName = "test"; const collName = "foo"; const ns = dbName + "." + collName;   const st = new ShardingTest({mongos: 1, config: 1, shards: 2, rs: {nodes: 1}});   assert.commandWorked(st.s.adminCommand({enableSharding: dbName})); assert.commandWorked(st.s.adminCommand({shardCollection: ns, key: {x: 1}}));   let collEntryBefore = st.s.getDB("config").getCollection("collections").find({ _id: ns }).toArray()[0]; print("collEntryBefore: " + tojson(collEntryBefore)); assert.neq(null, collEntryBefore.uuid);   jsTest.log("dropping collection " + ns); assert.commandWorked(st.s.getDB(dbName).runCommand({ drop: collName }));   let collEntryAfter = st.s.getDB("config").getCollection("collections").find({ _id: ns }).toArray()[0]; print("collEntryAfter: " + tojson(collEntryAfter)); // Expect this assert to fail, which demonstrates the bug. assert.neq(null, collEntryAfter.uuid);   st.stop(); })();
    • Sprint:
      Sharding 2017-12-04
    • Linked BF Score:
      0

      Description

      It may not cause any incorrect behavior (that I know of), but it's weird... we should make the write to mark the collection entry as 'dropped' use $set rather than a replacement-style update.

      Example collection entry after shardCollection (produced using the attached repro):

      collEntryBefore: {
          "_id" : "test.foo",
          "lastmodEpoch" : ObjectId("5a023322d22a4537cf47b2a1"),
          "lastmod" : ISODate("1970-02-19T17:02:47.296Z"),
          "dropped" : false,
          "key" : {
              "x" : 1
          },
          "unique" : false,
          "uuid" : UUID("052e805a-f4e5-4e0e-93a2-0865fbd59e1c")
      }
      

      How that collection entry looks after drop:

      collEntryAfter: {
          "_id" : "test.foo",
          "lastmodEpoch" : ObjectId("000000000000000000000000"),
          "lastmod" : ISODate("2017-11-07T22:26:43.080Z"),
          "dropped" : true
      }
      

      It also looks like dropCollection clears the lastmodEpoch (i.e., epoch); I don't see why it should do this?

        Attachments

          Activity

            People

            Assignee:
            esha.maharishi Esha Maharishi
            Reporter:
            esha.maharishi Esha Maharishi
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: