[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: |
|
||||||||||||||||||||||||
| 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. |