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

Operation time from donor may be greater than any oplog timestamp on the recipient after tenant migration

    • Fully Compatible
    • v5.0
    • Sharding 2021-06-28

      The recipient in a tenant migration is guaranteed to persist an oplog entry with a timestamp >= the migration's block timestamp, but cluster time can advance on the donor after the block timestamp has been selected (from writes to other tenant's data or internal collections). This means the operation time a client receives when reading from the donor may be greater than the block timestamp, so if it performs an afterClusterTime read on the recipient after the migration finishes, that timestamp may not exist in the recipient's oplog, leading to a stall waiting for write concern until the next write on the recipient - from any tenant, background activity, or the periodic noop writer (the next write is guaranteed to satisfy the afterClusterTime because cluster times from the donor are gossiped to the recipient). A similar problem exists in sharded clusters and is handled by writing a noop oplog entry, but this logic is disabled for standalone replica sets.

            jack.mulrow@mongodb.com Jack Mulrow
            jack.mulrow@mongodb.com Jack Mulrow
            0 Vote for this issue
            1 Start watching this issue


                Error rendering 'slack.nextup.jira:slack-integration-plus'. Please contact your Jira administrators.