[SERVER-30383] Preserve collection UUID in renameCollection across databases Created: 27/Jul/17 Updated: 31/Jul/17 Resolved: 31/Jul/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Geert Bosch |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Storage 2017-08-21 | ||||||||
| Participants: | |||||||||
| Description |
|
Currently renameCollection across databases:
We can change this to:
|
| Comments |
| Comment by Ian Whalen (Inactive) [ 31/Jul/17 ] |
|
Closing as we're going with |
| Comment by Ian Whalen (Inactive) [ 27/Jul/17 ] |
|
Hey Spencer, sorry, that was just my default to put anything 3.6 feature related under 3.5 Desired. Bumping to 3.5 Required now. |
| Comment by Spencer Brody (Inactive) [ 27/Jul/17 ] |
|
We'd need to make sure this works with rollback to a checkpoint. For that to work we'd need to make sure that the source collection is two-phase dropped so that we don't lose its data from the source database until the drop is replication committed. For that to work we could just give the source collection a new UUID while it's in drop-pending mode. We'd need to record that new UUID in the renameCollection oplog entry (so that the refetch based rollback implementation can undo the renameCollection properly), but recent work already added an extra field for the original collection UUID to the renameCollection oplog entries so we should be able to use that. The final question is whether the recoverToStableCheckpoint machinery will be able to properly restore the original source collection from it's drop-pending namespace and uuid to its original namespace and UUID. |