[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: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
If after the end of the clone phase, we have on the syncing node collection_a: UUID_1 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. |