WiredTiger history store and majority commit point cache pressure
Parent: WiredTiger cache eviction and dirty ratio · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for WiredTiger history store and majority commit point cache pressure. 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
- WT-3745 describes a historical MongoDB 3.6/lookaside feedback loop in which heavy updates caused replication lag, retained majority-read history increased cache pressure, and slowed oplog reads aggravated lag. Treat this as historical mechanism evidence, not as proof of identical behavior in modern history-store releases. (low confidence) [source]
- A firsthand MongoDB 4.4-to-5.0 migration report records history-store growth during member outages despite w:1, a one-second history window, and disabled flow control; restoring members reduced the file. This is one deployment report and does not establish a general growth rate or prove that lowering the minimum window bounds retained history. (low confidence) [source]
- For the documented PSA scenario, MongoDB describes temporarily setting the unavailable or lagging secondary to votes:0 and priority:0 so the remaining primary can advance majority commits, then using rs.reconfigForPSASet when restoring the secondary. This procedure changes voting and majority-write durability and requires topology-specific evaluation. (low confidence) [source]
- WT-6681 records a reproduced case of rapid history-store disk growth with a replica-set member down and was resolved Works as Designed. File growth alone therefore does not establish a memory leak, and the ticket's initial diagnostic hypotheses should not be presented as settled root causes. (low confidence) [source]
- Increasing minSnapshotHistoryWindowInSeconds requires retaining older modified values for a longer window and can increase disk usage. Inference: reducing that window is not a guaranteed remedy for majority-lag retention, because MongoDB separately requires durable history after the lagged commit point. (medium confidence) [source]
Problems, failure modes and limitations
- In a primary-secondary-arbiter replica set, an unavailable or lagging secondary can stall the majority commit point even while w:1 writes continue. Retaining post-commit-point history adds disk writes and can increase cache pressure; the oplog may also exceed its configured limit to preserve the commit point. (high confidence) [source]
- Starting with MongoDB 5.0, enableMajorityReadConcern cannot be disabled. The older workaround of disabling majority read concern is therefore not applicable to 5.0 and later deployments. (low confidence) [source]
- WT-18765 reports dirty history-store content that eviction cannot remove during the history-store checkpoint pass, with workload-specific dirty-ratio overshoots above the configured trigger. This is evidence that a dirty trigger is not a hard instantaneous ceiling, not a universal overshoot percentage. (low confidence) (verified as of 2026-10-26) [source]
- The replication README defines oldest_timestamp as the earliest timestamp with guaranteed retained history and states that it advances with, and cannot exceed, stable_timestamp. This links retention progress to replication's safe timestamp progress; it is not solely a matter of how recently the application requested a snapshot. (medium confidence) (verified as of 2026-10-30) [source]
Comparisons and alternatives
- WiredTiger stores non-obsolete older record versions in the on-disk history store while the newest committed version goes to the user table. Older versions can therefore be evicted rather than all remaining resident in cache. (high confidence) [source]
- The history store is a shared internal row-store table named WiredTigerHS.wt. Its records become reclaimable according to oldest-reader and oldest-timestamp visibility, rather than solely because wall-clock time has elapsed. (low confidence) [source]
- Netdata's MongoDB monitoring guidance correlates cache fill and dirty ratios with per-node replication lag, oplog windows and member states. This provides an operational way to investigate whether replication trouble accompanies history retention rather than diagnosing from a single cache gauge. (low confidence) [source]
- The develop-branch WT_CACHE structure distinguishes history-store in-memory bytes, dirty bytes and update bytes through bytes_hs, bytes_hs_dirty and bytes_hs_updates. Its comment warns that these cached accounting values can be outdated; they are internal fields rather than a promise of identically named serverStatus metrics. (low confidence) (verified as of 2026-10-30) [source]
Facts and statements
- Moving older versions out of a user page does not guarantee an equivalent drop in cache usage: history-store writes consume cache too. WT-14336 explicitly describes dirty-content movement from the data store to the history store as a source of cache pressure. (medium confidence) [source]
- Measure history-store cache residency separately from its on-disk size. Percona's serverStatus example exposes bytes belonging to the history store table in the cache, history-store on-disk size, and read/insert counters; WT-14336 adds the motivation for separate total, dirty and update-byte accounting. (medium confidence) [source]
- Retaining history does not require keeping every historical version resident in RAM: the history store exists partly so older versions can be evicted while remaining available to older readers. History retention can nevertheless increase cache and I/O work. (high confidence) [source]
- A long-running timestamped reader can prolong the lifetime of historical versions that it still needs. History-store cleanup depends on visibility to readers and the application's oldest timestamp, so committed writes from other transactions can create retained history while that reader remains open. (high confidence) [source]
- Percona's WiredTiger Details dashboard exposes cache occupancy and byte rates read into and written from the cache. These provide operational context for history-retention investigations, but those aggregate panels do not by themselves attribute activity to the history store. (low confidence) (verified as of 2026-10-29) [source]
- Netdata's transaction diagnostic workflow combines serverStatus transaction counters with currentOp transaction ages and WiredTiger cache measurements. It supplies a way to investigate old readers alongside cache pressure; an inactive transaction counter alone should not establish the causal diagnosis. (low confidence) [source]
Children
- No children recorded.