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

Generate, pin, and replicate minFetchTimestamp on donor shards in resharding atomically

    • Type: Icon: Task Task
    • Resolution: Won't Do
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • Sharding NYC
    • 125
    • 1

      Donor shards currently do two writes to generate, pin, and replicate the minFetchTimestamp value. First, donor shards write a no-op oplog entry and use its opTime as the minFetchTimestamp. Second, donor shards update the config.localReshardingOperations.donor document to set the minFetchTimestamp field. This two-step process can lead to cases where the generated opTime has already lagged behind the current oldest_timestamp value and has therefore become ineligible for pinning.

      repl::getNextOpTime() can be called within the WriteUnitOfWork to reserve an oplog slot. This oplog slot that can be used as the timestamp for the update to set the minFetchTimestamp field.

            Assignee:
            backlog-server-sharding-nyc [DO NOT USE] Backlog - Sharding NYC
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: