[SERVER-36951] applyOps should work with a createIndexes command without a UUID Created: 30/Aug/18  Updated: 29/Oct/23  Resolved: 19/Sep/18

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: None
Fix Version/s: 3.6.9, 4.0.3, 4.1.4

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

Issue Links:
Backports
Depends
Related
related to SERVER-82349 Mongo 7 crashes on applyOps index del... In Progress
related to SERVER-36015 Remove references to system.namespace... Closed
is related to TOOLS-2308 MongoDB 4.2 removes applyops handling... Closed
is related to SERVER-27992 replicate collection UUIDs Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0, v3.6
Sprint: Storage NYC 2018-09-24
Participants:

 Description   

applyOps should work with a createIndexes command without a UUID. It currently fails:

> db.adminCommand({applyOps: [{op:"c", ns: "test.$cmd", o: {createIndexes: "test", key: {a:1}, name: "a_1"}}]})
{
	"applied" : 1,
	"code" : 207,
	"codeName" : "InvalidUUID",
	"errmsg" : "uuid must be a 16-byte binary field with UUID (4) subtype",
	"results" : [
		false
	],
	"ok" : 0,
	"operationTime" : Timestamp(1535666215, 1),
	"$clusterTime" : ...
}



 Comments   
Comment by Githook User [ 25/Sep/18 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@10gen.com', 'username': 'DiannaHohensee'}

Message: SERVER-36951 a createIndexes operation inside applyOps is not required to have a UUID.

(cherry picked from commit 0d0ba866052fd2b9ceaaa66c2b725a02822b102d)
Branch: v3.6
https://github.com/mongodb/mongo/commit/19e9da9cdc76f69076c0212dcd6208e05ea71d7a

Comment by Githook User [ 24/Sep/18 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@10gen.com', 'username': 'DiannaHohensee'}

Message: SERVER-36951 a createIndexes operation inside applyOps is not required to have a UUID.

(cherry picked from commit 0d0ba866052fd2b9ceaaa66c2b725a02822b102d)
Branch: v4.0
https://github.com/mongodb/mongo/commit/74dea95986ff33ab9d0d757b7a38b608a67d6f21

Comment by Shane Harvey [ 24/Sep/18 ]

Yes that would be great.

Comment by Dianna Hohensee (Inactive) [ 24/Sep/18 ]

shane.harvey, do you want v4.0 and v3.6 backports?

Comment by Githook User [ 19/Sep/18 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@10gen.com', 'username': 'DiannaHohensee'}

Message: SERVER-36951 a createIndexes operation inside applyOps is not required to have a UUID.
Branch: master
https://github.com/mongodb/mongo/commit/0d0ba866052fd2b9ceaaa66c2b725a02822b102d

Comment by Dianna Hohensee (Inactive) [ 18/Sep/18 ]

Ohhh, the collection UUID in one replica set is always different than the collection UUID in the target replica set. So MongoMirror will always need to strip the UUID field. Okay, cool. I'll go ahead with the change then. Thanks for the clarifications.

Comment by Shane Harvey [ 18/Sep/18 ]

Yes that's exactly the problem where trying to solve. This ticket would remove the need to query the target collection's UUID before running each createIndexes command.

If UUID is no longer provided, though, then the createIndexes can potentially run on a different collection, in the case that the collection gets dropped and recreated. Would that be acceptable behavior?

I think this is okay. This race condition also exists when the client provides the UUID since listCollections could give us the UUID of either the new collection or the old collection.

Comment by Dianna Hohensee (Inactive) [ 18/Sep/18 ]

shane.harvey

It looks like the problem you're trying to address is migrating data from v3.4 or older replica sets to v3.6+ version replica sets, right?

I can change this so that the following works

db.adminCommand({applyOps: [{op:"c", ns: "test.$cmd", o: {createIndexes: "test", v: 2, key: {a:1}, name: "a_1"}}]})

without a 'uuid' field and with a 'v' field, which is required once you get past the UUID error.

If UUID is no longer provided, though, then the createIndexes can potentially run on a different collection, in the case that the collection gets dropped and recreated. Would that be acceptable behavior? We would technically try to parse for 'uuid' before falling back onto 'ns', so perhaps you would want to provide 'uuid' when possible with v3.6+ version data sources.

It is presently possible to get a collection's UUID via the listCollections command: this JS test currently performs createIndexes in applyOps that way.

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