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

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v5.0
    • Sprint:
      Sharding 2021-06-28

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            jack.mulrow Jack Mulrow
            Reporter:
            jack.mulrow Jack Mulrow
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: