-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
Sharding 2020-10-19, Sharding 2020-11-02, Sharding 2020-11-16, Sharding 2020-11-30, Sharding 2020-12-14
-
17
SERVER-49789 made a TenantMigrationDonorService::Instance create a RemoteCommandTargeterRS for the recipient replica set at the beginning of its run() and capture the targeter into all the continuations in its future chain (like here).
See that ticket's description for background.
We handled destroying the donor's ReplicaSetMonitor for the recipient once the donor completed the migration by calling ReplicaSetMonitor::remove in the RemoteCommandTargeterRS destructor.
However, if the donor was migrating two tenants to the same recipient concurrently, the two migrations would be sharing the same ReplicaSetMonitor, and the first migration to finish would rip the ReplicaSetMonitor out from under the second migration.
This ticket is to ensure the ReplicaSetMonitor is only removed when the ReplicasSetMonitor does not have any more users.
There is already a commented-out test case for this here.
- is depended on by
-
SERVER-51440 Cleanup refcounting and lifetime of ReplicaSetMonitor
- Closed
- is related to
-
SERVER-50189 Replace ReplicaSetMonitorManager::removeMonitor with a custom deleter for shared_ptr<ReplicaSetMonitor>
- Backlog
-
SERVER-51413 RemoteCommandTargeterRS custom deleter in TenantMigrationDonorService::Instance::run does not need to capture 'this' or 'self'
- Closed
- related to
-
SERVER-53276 After tenant migration, recipient side RSM to donor is not garbage collected
- Closed
-
SERVER-50093 Test that donor supports running multiple tenant migrations concurrently
- Closed