[SERVER-31865] setFCV on config server should only generate UUIDs for non-dropped sharded collections Created: 07/Nov/17  Updated: 30/Oct/23  Resolved: 30/Nov/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.6.0-rc2
Fix Version/s: 3.6.1, 3.7.1

Type: Bug Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6
Steps To Reproduce:

(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
Participants:
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?



 Comments   
Comment by Githook User [ 05/Dec/17 ]

Author:

{'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com', 'name': 'Esha Maharishi'}

Message: SERVER-31865 setFCV on config server should only generate UUIDs for non-dropped sharded collections

(cherry picked from commit 0fd5cb5718f511f42a8c6622285d97648e9a3fa0)
Branch: v3.6
https://github.com/mongodb/mongo/commit/b1239123fae587c6e143eca2ff98f5e7e2ef22c4

Comment by Githook User [ 30/Nov/17 ]

Author:

{'name': 'Esha Maharishi', 'username': 'EshaMaharishi', 'email': 'esha.maharishi@mongodb.com'}

Message: SERVER-31865 setFCV on config server should only generate UUIDs for non-dropped sharded collections
Branch: master
https://github.com/mongodb/mongo/commit/ea168edc260073085397bf462f652c082db506b8

Comment by Kaloian Manassiev [ 10/Nov/17 ]

Instead of doing this, we should fix the setFCV query for collection discovery.

Comment by Esha Maharishi (Inactive) [ 07/Nov/17 ]

It's also odd because a UUID gets (re)generated for these dropped collections on setFCV. We should also make the query that setFCV uses to find collections that need UUIDs exclude dropped collections.

Comment by Esha Maharishi (Inactive) [ 07/Nov/17 ]

Noticed while investigating BF-6349.

Generated at Thu Feb 08 04:28:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.