[SERVER-32360] Rename collection with dropTarget should drop the target even if the source doesn't exist Created: 15/Dec/17 Updated: 16/Mar/18 Resolved: 20/Feb/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: | Xiangyu Yao (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||||||
| Sprint: | Repl 2018-01-15, Repl 2018-01-29, Storage 2018-02-12, Storage 2018-02-26 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 61 | ||||||||||||||||
| Description |
|
Consider the following scenario: Create db.collection1 with UUID U1 at time T1. Now do an initial sync, starting the clone at some time after T4, but with the oplog replay start point of T2. After the clone, no collections exist in db. After applying the entry at T2, db.collection2 (U2) exists. Applying the entry at T3 fails. The drop at T4 is for UUID U1, so it fails too. Now initial sync is done and a spurious collection2 exists. The rename should have dropped it, despite the source not existing. |
| Comments |
| Comment by Xiangyu Yao (Inactive) [ 20/Feb/18 ] |
|
Merging this ticket with |
| Comment by Judah Schvimer [ 02/Feb/18 ] |
|
Sending this to storage to do in conjunction with |
| Comment by Judah Schvimer [ 15/Dec/17 ] |
|
This should probably happen on secondaries. I don't think primaries doing a renameCollection that fails should still drop their target. |