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

XMLWordPrintableJSON

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

      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:
            [DO NOT USE] Backlog - Sharding NYC
            Reporter:
            Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: