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

Fail and log the operation when out-of-order keys are detected in WiredTiger

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.2.24, 4.4.19, 5.0.15, 6.3.0-rc0, 6.0.5
    • None
    • None
    • Storage Execution
    • Fully Compatible
    • ALL
    • v6.2, v6.0, v5.0, v4.4, v4.2
    • Execution Team 2022-12-26, Execution Team 2023-02-06

    Description

      During an index rebuild, IndexBuildsManager::startBuildingIndexForRecovery will go back to the beginning in the case of a write conflict exception in a partial batch. This can lead to "infinite looping" behaviour for some classes of cursor problems (see HELP-40283).

      It should do something that makes failures a bit clearer, e.g. having a retry limit if the occasional write conflict is expected, or possibly aborting the build for that index.

      This issue can occur when data corruption is present such that keys returned from the storage engine are not in ascending order.

      Update
      When an out-of-order key is detected, we will no longer throw a WriteConflictException when performing a collection scan. The DataCorruptionDetected error will be thrown instead. For v6.3 and up a new health log entry will be inserted into the local.system.healthlog collection that includes both keys, namespace, ident, scan direction and a stack trace.

      Attachments

        Issue Links

          Activity

            People

              gregory.wlodarek@mongodb.com Gregory Wlodarek
              will.korteland@mongodb.com Will Korteland
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: