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

(3.6) Rewriting updates as modifications incorrectly considers logging state

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Fixed
    • Affects Version/s: 3.6.14, 3.6.15
    • Fix Version/s: 3.6.16
    • Component/s: Storage
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Execution Team 2019-11-18
    • Linked BF Score:
      25

      Description

      Issue Status as of Nov 26, 2019

      ISSUE DESCRIPTION AND IMPACT

      This issue can lead to document-level corruption when MongoDB recovers from an unclean shutdown.

      Updates to documents are both journaled and stored in the WiredTiger cache page containing the document. They can be represented in logical form, or in physical form as binary diffs when it is more efficient to do so.

      When starting up from an unclean shutdown, MongoDB replays the journal to recover writes performed after the last consistent on-disk checkpoint. It is possible for journaled writes that preceded the checkpoint time to be replayed, which is safe as long as journal entries are idempotent.

      In MongoDB versions 3.6.14 and 3.6.15, this bug allows updates that change the size of values to be eligible for representation as binary diffs, which is not an idempotent way to represent that kind of change.

      Because this bug allows size-changing updates to be represented in a non-idempotent form, recovering from an unclean shutdown can introduce corruption in documents that were updated between the last checkpoint time and the log recovery time for the unclean shutdown.

      AFFECTED VERSIONS
      MongoDB 3.6.14, 3.6.15.

      ISSUE STATUS
      This issue is corrected in MongoDB version 3.6.16.

      DIAGNOSIS AND WORKAROUNDS
      Impacted nodes will log or return BSONElement: Bad Type errors when accessing or updating impacted documents. The ideal resolution is to resync an impacted node from an un-impacted node, but --repair is also an option.

      No workarounds exist for this issue.

      original description

      It was never intended for logged tables to have their updates expressed as diffs that could change the size of the value.

      However evaluating whether a table was logged used an incorrect method. The method was created for a feature that got postponed to 4.0 and was otherwise dormant and untested.

      In 3.6, all tables are logged. The optimization for rewriting updates as modifications should be disabled altogether.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: