[SERVER-55193] Support back-to-back migration of the same tenant Created: 15/Mar/21  Updated: 29/Oct/23  Resolved: 12/Apr/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.9.0-rc1, 5.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Lingzhi Deng Assignee: Jason Chan
Resolution: Fixed Votes: 0
Labels: pm-1791_non-cloud-blocking, pm-1791_optimizations
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
is related to SERVER-55380 Out of order oplog application for st... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.9
Sprint: Repl 2021-04-05, Repl 2021-04-19
Participants:

 Description   

It looks like there is a case where we need both a donor and recipient TenantMigrationAccessBlocker.  This is when we do a successful migration of A->B, then immediately (before the garbage collection period has elapsed) do a migration of B->C.  The migration B->C currently would fail due to conflicting migration errors (until after the garbage collection period). We can handle this by

  1. Immediately GCing the recipient mtab (but this opens up old reads)
    • We could instead replace the recipient mtab with a donor mtab (with a special flag?) that also block old reads
  2. Combining the two access blockers
  3. Allowing both to exist simultaneously

But before we do any of these, we should confirm with Cloud on whether this is something Cloud is expected to do.



 Comments   
Comment by Githook User [ 12/Apr/21 ]

Author:

{'name': 'Jason Chan', 'email': 'jason.chan@mongodb.com', 'username': 'jasonjhchan'}

Message: SERVER-55193 Support back-to-back tenant migrations

(cherry picked from commit 7c4fdf48f8882818e778c3c2931b0e24aa99711d)
Branch: v4.9
https://github.com/mongodb/mongo/commit/74492a41157f8035ed658c75c006a784f55592e3

Comment by Githook User [ 12/Apr/21 ]

Author:

{'name': 'Jason Chan', 'email': 'jason.chan@mongodb.com', 'username': 'jasonjhchan'}

Message: SERVER-55193 Support back-to-back tenant migrations
Branch: master
https://github.com/mongodb/mongo/commit/7c4fdf48f8882818e778c3c2931b0e24aa99711d

Comment by Jason Chan [ 05/Apr/21 ]

As described, this ticket is meant to handle the back-to-back migration case of A -> B -> C, where A,B,C are all separate replica sets.

We do not expect the back-to-back immediate migration case of A - migration 1 -> B - migration 2 -> A because the migration protocol guarantees that Cloud will wait the "grace period" to allow clients to finish exhausting their cursors on replica set A (from migration 1) before cleaning up the orphaned data.

Implementation-wise, this means we can guarantee the following:

  • Each node has at most only one donor MTAB and one recipient MTAB at a time.
  • The only valid case where a replica set can have two existing MTABs is in the migration scenario of A->B->C (where we are B). The recipient MTAB must have already been marked garbage collectable when starting the migration from B->C.
Generated at Thu Feb 08 05:35:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.