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

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.2.24, 4.4.19, 5.0.15, 6.3.0-rc0, 6.0.5
    • Affects Version/s: None
    • Component/s: 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

      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.

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

              Created:
              Updated:
              Resolved: