[SERVER-59492] Post-Merge cleanup Created: 20/Aug/21  Updated: 03/Mar/23  Resolved: 03/Mar/23

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

Type: Task Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: [DO NOT USE] Backlog - Server Serverless (Inactive)
Resolution: Duplicate Votes: 0
Labels: shard-merge-milestone-3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-61144 Finish importing donated collections ... Closed
depends on SERVER-63454 Don't require tenantId for shard merge Closed
is depended on by SERVER-57991 Architecture Guide updates for PM-2353 Closed
Duplicate
duplicates SERVER-72218 Implement garbage collection procedur... Closed
Assigned Teams:
Serverless
Participants:

 Description   

In Multitenant Migrations, it is Cloud's responsibility to clean up migrated data from the donor by calling dropDatabase on the migrated tenant's DBs. It seems cleaner and more maintainable for mongod to be responsible for post-migration cleanup. At some point in the Merge project let's consider whether it's worthwhile to make this change.



 Comments   
Comment by Suganthi Mani [ 03/Mar/23 ]

We decided Server will do perform the GC procedure on the imported data on migration abort (see the design doc)

Comment by A. Jesse Jiryu Davis [ 15/Feb/22 ]

We'll design this in Milestone 3.

Comment by Siyuan Zhou [ 09/Feb/22 ]

The cleanup logic on failure seems very similar to that of recipientForgetMigration. Having Cloud to clean up the data seems a leak of implementation details. In phase 2, we may need extra authentication (tenant tokens) to drop tenants' collections. Doing so for many tenants will be more complex than now.

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