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

Retry timestamping secondary background index builds

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.0.2, 4.1.2
    • Fix Version/s: 4.0.3, 4.1.4
    • Component/s: Storage
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0
    • Sprint:
      Storage NYC 2018-09-24
    • Linked BF Score:
      5

      Description

      Secondary background index builds may complete at any time after they start. It's important the completion is timestamped in order relative to other operations on the collection, but it's not intrinsically important what timestamp it gets (there are however some external constraints):

      1. Choosing a time that hasn't yet been seen by the system can result in readers to wait for an optime that will never come.
      2. Choosing a time that has already happened can race with setting the stable timestamp.

      Of the two constraints, the first one is more sensitive to testing failures. The proposed solution is to continue to timestamp the write with the latest logical clock value, but retry (instead of fasserting) in the event the index completion lost the race with the stable timestamp.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: