validate full versus BSON conformance checks across upgrades
Parent: Corruption (validate, --repair, wt CLI) · Published reference · snapshot 2026-10-27
↓ Facts as markdownall context files
Source-anchored research for validate full versus BSON conformance checks across upgrades. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- MongoDB master resmoke validate_database currently sets full:false and checkBSONConformance:true. Its comment says some fixtures keep the oplog applier active and full:true can cause ObjectIsBusy during internal finds. This is test-harness configuration, not a production runbook requirement. (low confidence) (verified as of 2026-10-27) [source]
Measurements and reference values
- The 8.3 option separation accompanies validation changes: validation now checks for documents exceeding 16 MB. Therefore an unchanged command can produce different findings after an upgrade, even when no new damage occurred. The last sentence is an inference from the changed check coverage. (high confidence) [source]
Problems, failure modes and limitations
- The engineering rationale for making BSON conformance opt-in was excessive warning output, including deprecated BSON binary data. SERVER-110284 targets 8.3.0-rc0, while SERVER-106872 describes millions of warning log lines obscuring other issues under log ID 6825900; these are engineering issue descriptions, not independent incident counts. (high confidence) [source]
- SERVER-136132 describes ValidateAdaptor::validateRecord swallowing a NonConformantBSON result and continuing to use a document whose later BSON could be structurally invalid. The issue lists fixes in 9.1.0-rc0 and 9.1.0-rc1024 and no affected versions, so it cannot establish which released 7.x or 8.x patch versions are vulnerable or fixed. (low confidence) (verified as of 2026-10-27) [source]
- The documented checkBSONConformance option cannot be combined with repair:true or metadata:true. A runbook must therefore schedule its conformance check separately from those modes. (high confidence) [source]
- Additional BSON conformance checks increase validation time and report issues as warnings. The option cannot be combined with repair:true or metadata:true. A conformance warning alone does not establish unreadable BSON corruption. (high confidence) [source]
Facts and statements
- For WiredTiger, full validation forces a checkpoint, flushes in-memory data to disk, and verifies on-disk data. The oplog is an exception: full validation skips the more thorough check. BSON conformance checking alone does not request that full storage verification. (high confidence) [source]
- checkBSONConformance was introduced in MongoDB 6.2 to enable comprehensive BSON checks. The option defaults to false, adds validation time, and reports conformance issues as warnings. (high confidence) [source]
- MongoDB 8.0 documentation says full:true enables checkBSONConformance. Starting in 8.3, full:true no longer enables it automatically; BSON conformance remains an explicit opt-in with a default of false. (high confidence) [source]
- For an upgrade runbook that requires both full storage validation and additional BSON conformance checking on 8.3, explicitly request db.runCommand({validate:"myCollection",full:true,checkBSONConformance:true}). This is a recommendation derived from the documented independent options and the 8.3 behavior change. (high confidence) [source]
- Validation output distinguishes nInvalidDocuments, which counts unreadable corrupt BSON or size mismatches, from nNonCompliantDocuments, which includes schema and, since 6.2, BSON/time-series requirements. Noncompliant documents are not counted as invalid documents. (medium confidence) [source]
- SERVER-106873 records that some column-compressed time-series errors required checkBSONConformance:true in the older behavior and lists 8.0.10 as affected. The ticket closed as Duplicate with no fix version. SERVER-112511 separately records recategorizing BSON checks by severity, fixed for 8.3.0-rc0; neither record proves complete corruption-detection coverage on every patch. (high confidence) [source]
- The checkBSONConformance option was introduced in MongoDB 6.2. It requests additional BSON specification checks; full controls the thoroughness of collection and index validation. These options represent different dimensions of validation. (high confidence) [source]
- Foreground validation takes an exclusive collection lock and blocks reads and writes. The 8.3 method documentation recommends a secondary that is not serving reads or isolation through rolling maintenance or a hidden member. Plan upgrade verification around this operational cost. (high confidence) [source]
Children
- No children recorded.