[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:
Related
is related to SERVER-30371 Separate renameCollection across DB c... Closed
Sprint: Storage 2017-08-21
Participants:

 Description   

Currently renameCollection across databases:

  1. takes a global lock
  2. copies the data from the source collection to a temporary collection (with a different UUID) in the target database
  3. atomically drops the source collection and renames the temp collection in the target db to its final non-temp name in the target db.

We can change this to:

  1. Take a global clock
  2. Copy the data from the source collection to a temporary collection (with a different UUID) in the target database
  3. Atomically move the source collection to the drop-pending namespace, change its UUUID, rename the temp collection in the target db to its final non-temp name in the target db, and change the UUID on the dest collection to the UUID of the original source collection.


 Comments   
Comment by Ian Whalen (Inactive) [ 31/Jul/17 ]

Closing as we're going with SERVER-30371 instead.

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.

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