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

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

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Won't Do
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Sharding
    • Sharding NYC
    • 125
    • 1

    Description

      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.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: