Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-48941

[recovery] Make startup recovery recover a tenant migration donor's in-memory state

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.8.0
    • Affects Version/s: None
    • Component/s: None
    • Fully Compatible
    • Sharding 2020-09-21

      This ticket is to make mongod recover on startup which database prefixes to block/reject operations for.

      • Add a function void recoverTenantMigrationAccessBlockers(OperationContext* opCtx) to migrating_tenant_donor_util.cpp that scans config.migrationDonors (see example), and for each doc:
        • Creates a TenantMigrationAccessBlocker for that “databasePrefix” and add()'s it to TenantMigrationAccessBlockerByPrefix
        • If the doc has "blockTimestamp" set, call startBlockingWrites() and then startBlockingReadsAfter() with the “blockTimestamp” on the TenantMigrationAccessBlocker
        • If the doc's state is “commit” , also call commit() on the TenantMigrationAccessBlocker
        • If the doc's state is “abort” , also call abort() on the TenantMigrationAccessBlocker
      • Call the new recoverTenantMigrationAccessBlockers function just before where prepared transactions are recovered on startup

      This ticket should also test that the code works by restarting the donor

      • while the migration is in the "blocking" state
      • after the migration has committed
      • after the migration has aborted

      and confirming that the in-memory state was recovered correctly. See tenant_migration_donor_state_machine.js for an example of pausing a migration while it's blocking and checking the donor's in-memory state.

            Assignee:
            jason.zhang@mongodb.com Jason Zhang
            Reporter:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: