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

(3.6) Rewriting updates as modifications incorrectly considers logging state

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Critical - P2 Critical - P2
    • 3.6.16
    • Affects Version/s: 3.6.14, 3.6.15
    • Component/s: Storage
    • None
    • Fully Compatible
    • ALL
    • Execution Team 2019-11-18
    • 25

      Issue Status as of Nov 26, 2019


      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.

      MongoDB 3.6.14, 3.6.15.

      This issue is corrected in MongoDB version 3.6.16.

      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.

            daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
            daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
            0 Vote for this issue
            21 Start watching this issue