Critical - P2 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.
- related to
-
WT-5247 Ensure that only idempotent modify operations are logged
-
- Closed
-