Time series bucket reopening (archived and query-based)
Parent: Bucket fragmentation remediation (re-insert/merge) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Time series bucket reopening (archived and query-based). 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
- In the inspected bucket_catalog.cpp, decideQueryBasedReopening disables query-based reopening when the rollover reason is not kTimeBackward; candidate eligibility alone does not guarantee a query attempt. (low confidence) [source]
- SERVER-106179 reports high CPU and cache-read activity in a MongoDB 7.0.18 sharded time-series workload and suspects internal reopening reads. The report presents possible explanations, not a confirmed reopening root cause; its resolution is Won’t Do with no fix version. (low confidence) (verified as of 2025-07-16) [source]
Problems, failure modes and limitations
- SERVER-106854 reports that nested metadata arriving in varying field order can fail reopen verification, retry inserts in new buckets, and cause poor bucketing. The issue lists fixes in 8.0.20, 8.2.2 and 8.3.0-rc0; it does not enumerate affected releases. (low confidence) (verified as of 2026-02-03) [source]
- SERVER-95067 describes possible acknowledged loss of the first document when retryable multi-document unordered inserts, a reopening index, and concurrent writers targeting the same bucket coincide. It identifies affected releases 7.0.0–7.0.15 and 8.0.0–8.0.3, with fixes in 7.0.16 and 8.0.4. Its historical workarounds disable query-based reopening by dropping the index, or use ordered inserts when that index cannot be dropped. (low confidence) (verified as of 2025-01-29) [source]
- Frozen buckets are ineligible for further inserts after compression failure. SERVER-86085 explains why retrying a write conflict cannot resolve a frozen bucket: its frozen state will not change. (low confidence) [source]
- Reopening appends incoming measurements to an eligible existing bucket; it does not merge existing buckets. If reopening cannot yield a suitable bucket, insertion can allocate another bucket, so automatic reopening does not guarantee fragmentation repair. (medium confidence) (verified as of 2026-10-30) [source]
- In the examined implementation, reopening releases the stripe lock during disk work and revalidates catalog state afterward. Write conflicts can trigger bounded retries; failure to find a usable bucket can ultimately cause a fresh allocation. (low confidence) (verified as of 2026-10-30) [source]
- Reopening failure telemetry must be interpreted by release: the 8.0 manual documents numBucketReopeningsFailed, while SERVER-102677 records finer-grained failure reasons for 8.2.0-rc0 and links a separate removal of the aggregate counter. A candidate can fail checks for era mismatch, hash collision or malformed data. (medium confidence) (verified as of 2025-04-10) [source]
Facts and statements
- If no suitable open bucket exists, insertion can fetch an archived bucket by _id or query disk buckets, then reconstruct catalog state. The implementation tries an archived candidate before a query candidate. (high confidence) (verified as of 2026-10-30) [source]
- Archival retains a small catalog record after removing most in-memory state. Further memory pressure can evict that record; the bucket can still qualify for query-based reopening. (medium confidence) (verified as of 2026-10-14) [source]
- Reopening queries filter on exact metadata, a time range, count and size limits, and control.closed missing or false. (low confidence) (verified as of 2026-10-14) [source]
- The README requires a supporting {<metaField>:1,<timeField>:1} index for query-based reopening and says new collections receive it automatically from 6.3 onward; absence disables that path. (low confidence) (verified as of 2026-10-14) [source]
- A bucket with control.closed set to true is permanently ineligible for reopening. Catalog removal or time-span rollover does not by itself imply that permanent state. (low confidence) (verified as of 2026-10-14) [source]
- Compressed reopening reconstructs BSONColumn builders from existing binaries. Scalar columns support optimized reconstruction; object or array columns can require full decompression and reconstruction of the affected column, so reopening cost depends on data shape. (low confidence) (verified as of 2026-10-14) [source]
- MongoDB 8.0 serverStatus.bucketCatalog separates numBucketsFetched, numBucketsQueried and numBucketsReopened. numBucketFetchesFailed counts unsuitable archived fetches; numBucketQueriesFailed counts queries without a candidate. These counters distinguish lookup attempts from successful reuse. (low confidence) (verified as of 2026-10-30) [source]
- Reopening appends new measurements to a selected existing bucket; it does not itself merge already persisted buckets. A September 2023 vendor forum reply explicitly said internal bucket merging was unavailable at that time; this historical statement does not establish current feature availability. (low confidence) (verified as of 2023-09-04) [source]
- SERVER-99527 documents a separate defect on 7.0.0–7.0.15 and 8.0.0–8.0.3: non-metadata deletes can change control.min without changing the bucket _id timestamp, allowing later query-based reopening outside the proper span. Consequences include premature TTL expiry and incomplete time-filtered results; fixes are 7.0.16 and 8.0.4. (low confidence) (verified as of 2025-08-07) [source]
- A 2023 community load-test report observed near-singleton buckets and high numBucketsClosedDueToCachePressure during interleaved collection loads. This is anecdotal evidence that bucket reuse can degrade under load, not proof of a reopening defect or a validated tuning prescription. (low confidence) (verified as of 2023-10-19) [source]
- For collections with metadata, query-based reopening requires the {metaField: 1, timeField: 1} index; without metadata, the documented supporting index is {timeField: 1}. Absence disables the query path, not archive-based reopening. (medium confidence) (verified as of 2026-10-30) [source]
- Before removing an apparently unused reopening index, review all replica-set members and the observation window. Percona PMM documents per-node access tracking since restart; combined with MongoDB’s index prerequisite, this supports checking the ingestion impact before dropping that index. This recommendation is an inference from the two sources. (medium confidence) (verified as of 2026-10-26) [source]
- OneUptime warns that late arrivals can reopen older buckets or create small new buckets and degrade compression, but supplies no controlled reopening benchmark in the relevant section; treat this as qualitative practitioner guidance. (low confidence) (verified as of 2026-03-31) [source]
Children
- No children recorded.