MongoDB primary-driven index builds (PDIB)
Parent: Resumable index builds · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-6b0d6e198335
↓ Facts as markdownall context files
Source-anchored research for MongoDB primary-driven index builds (PDIB). 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.
Definitions
- A duplicate ci crash after PDIB resume is not sufficient to identify the wildcard metadata bug. [redacted] describes ordinary integer-field data keys being duplicated even with the SERVER-127943 fix present; it attributes that case to an unsafe nonexistent-key guarantee during resumed loading. (medium confidence) [source]
How it works
- SERVER-127943 documents a secondary WT_DUPLICATE_KEY crash when a multikey wildcard PDIB resumes at bulk-load iteration zero. The reported trigger excludes ordinary multikey B-tree indexes, scalar wildcards, non-resumed builds, and resumes in the middle or end of bulk load. (low confidence) [source]
- [redacted] records a distinct PDIB bug, "Resuming PDIB when retrying skipped records can lose multikey," as fixed in 9.1.0-rc0 and 9.1.0-rc1023. Its public page gives no mechanism or reproducer, so attributing a particular explain result to this bug requires additional evidence. (low confidence) (verified as of 2026-09-28) [source]
Problems, failure modes and limitations
- [redacted] documents a PDIB secondary validation failure after indexing an array-valued field: Index is not multikey but document has multikey data. This is evidence of a metadata propagation defect, not an explanation of a new multiKeyPaths format. (low confidence) [source]
- SERVER-127640 requested testing the PDIB resume path when serialized sorter range metadata exceeds the 16 MiB BSON limit. Its resolution is Gone away with no fix version, so the request alone does not establish that the test shipped or that an oversized-state bug was fixed. (low confidence) (verified as of 2026-07-28) [source]
- SERVER-127943 documents a historical failure when a multikey wildcard PDIB resumes at bulk-load iteration zero: the resumed bulk builder restores _isMultiKey and _indexMultikeyPaths but omits _hasMultiKeyMetadataKeys, bypassing metadata-key deduplication and emitting duplicate ci operations that can crash a secondary with WT_DUPLICATE_KEY. [redacted] independently describes the fix as restoring the wildcard metadata flag on resume. (medium confidence) [source]
Comparisons and alternatives
- PDIB uses the bulk builder but spills sorted keys into a replicated storage-engine table, rather than relying on each replica to generate its own sorted keys. (low confidence) [source]
Facts and statements
- PDIB builds the index on the primary and replicates internal container writes through ci/cd oplog entries; secondaries apply those entries. The implementation README says commit quorum does not apply. (low confidence) [source]
- PDIB supports resuming on step-up after failover or primary restart. [redacted] explicitly says old test exclusions claiming that primary-driven builds are not resumable are outdated; the README says a failed resume aborts the build. (medium confidence) (verified as of 2026-10-16) [source]
- In the SERVER-127943 diagnosis, the resume constructor restored _indexMultikeyPaths and _isMultiKey but omitted _hasMultiKeyMetadataKeys. That omitted flag disabled deduplication of identical wildcard metadata keys and caused duplicate replicated container inserts. (low confidence) [source]
- [redacted] states that [redacted] made PDIB piggyback multikey updates in insert ("i") side writes. Its September 23 record leaves the improvement to store them in separate "m" entries open and unresolved. (low confidence) (verified as of 2026-09-23) [source]
- For an unexpected multikey result after PDIB failover, metadata preservation and replay are concrete investigation targets: vendor records separately describe missing secondary multikey state and lost wildcard-metadata deduplication on resume. This is a troubleshooting inference, not evidence that every multiKeyPaths anomaly is a PDIB bug. (medium confidence) [source]
- In SERVER-127943, wildcard multikey metadata keys use a reserved RecordId shared across documents, so identical metadata keys require deduplication. The documented reproducer excludes scalar wildcards, ordinary multikey B-tree indexes, non-resumed builds, and resumes after the initial metadata keys have already been loaded. (low confidence) [source]
- [redacted] records the ordering task "Set multikey before adding keys for PDIB" as fixed, with fix versions 9.1.0-rc0 and 9.1.0-rc1023. The public page has no explanatory description, so it supports the task and listed versions, not a detailed account of the implementation. (low confidence) (verified as of 2026-09-29) [source]
- Adding a multikey side-write operation type does not establish that PDIB already stores multikey updates in dedicated entries: [redacted] is fixed, while its dependent integration improvement [redacted] remains open in the inspected records. (medium confidence) (verified as of 2026-09-30) [source]
Children
- No children recorded.