[SERVER-34727] Rename collection during initial sync drops extra collection Created: 27/Apr/18  Updated: 27/Apr/18  Resolved: 27/Apr/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Matthew Russotto Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-33956 A sequence of rename and create colle... Closed
Related
is related to SERVER-33087 Fix the use of dropTarget in renameCo... Closed
Operating System: ALL
Participants:

 Description   

If after the end of the clone phase, we have on the syncing node

collection_a: UUID_1
collection_b: UUID_2
collection_c: UUID_3

and we replay a renameCollection opcode renaming UUID_1 to collection_b with dropTarget: UUID_3, we will correctly rename UUID_2 to a temporary name, but also incorrectly drop UUID_3. When we then go to create UUID_3 in a later oplog entry, it may be in drop_pending state and refuse to be re-created.



 Comments   
Comment by Matthew Russotto [ 27/Apr/18 ]

It's safe to drop it (provided you can save it from drop-pendingland) but it turns out that's actually not what happened – in fact, now that I think about it, it can't happen, because you'll never get a dropTarget with a UUID that you haven't created yet. In this case I think what actually happened is we had a dropTarget of "true" because the related backports weren't in the 3.6 version yet.

Comment by Judah Schvimer [ 27/Apr/18 ]

If dropTarget UUID_3 is specified, why is it safe to not drop it? We've had the opposite problem in the past. I think the problem here is that when we go to create UUID_3, we should rename the drop-pending collection to the requested name so the post-image is maintained.

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