[SERVER-54653] Make ContinuousTenantMigration hook garbage collect each migration before starting the next one Created: 19/Feb/21  Updated: 29/Oct/23  Resolved: 19/Feb/21

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

Type: Task Priority: Major - P3
Reporter: Cheahuychou Mao Assignee: Cheahuychou Mao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-53582 Create and remove TenantMigrationAcce... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2021-02-22
Participants:

 Description   

After SERVER-53582, the ContinuousTenantMigration hook is expected to no longer work since it cannot start migration rs1 -> rs2 without garbage collecting migration rs0 -> rs1. The reason is that the donor MTAB and recipient MTAB are both stored in the MTABRegistry so it will get ConflictingOperationInProgress error when it tries to start migration rs1 -> rs2. 

 
It is an overkill to support starting an outgoing migration before garbage collecting last incoming migration for a tenant just to make the hook work since:

  1. Cloud will never run migrations for a tenant so close to each other and without garbage collecting the previous one (although there is nothing illegal with what the hook does).
  2. Given 1, it should be useful to throw an error when we detect that Cloud is trying to start a migration for a tenant without garbage collecting the previous one.

So the hook should just garbage collect each migration before starting the next one. 



 Comments   
Comment by Githook User [ 19/Feb/21 ]

Author:

{'name': 'Cheahuychou Mao', 'email': 'mao.cheahuychou@gmail.com', 'username': 'cheahuychou'}

Message: SERVER-54653 Make ContinuousTenantMigration hook garbage collect each migration before starting the next one
Branch: master
https://github.com/mongodb/mongo/commit/a2ad8a9496400df2b01d9901f4cc3008fbcf20a6

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