[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: |
|
||||||||||||||||||||||||||||
| 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:
|
| Comments |
| Comment by Githook User [ 25/Sep/18 ] | |
|
Author: {'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@10gen.com', 'username': 'DiannaHohensee'}Message: (cherry picked from commit 0d0ba866052fd2b9ceaaa66c2b725a02822b102d) | |
| Comment by Githook User [ 24/Sep/18 ] | |
|
Author: {'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@10gen.com', 'username': 'DiannaHohensee'}Message: (cherry picked from commit 0d0ba866052fd2b9ceaaa66c2b725a02822b102d) | |
| 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: | |
| 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.
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 ] | |
|
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
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. |