# WiredTiger history store and majority commit point cache pressure > Source-anchored research for WiredTiger history store and majority commit point cache pressure. Run status: COMPLETED. Parent: [WiredTiger cache eviction and dirty ratio](https://llms-explorer.com/tree/wiredtiger-cache-eviction-and-dirty-ratio/) · 4 facets · 19 facts · page: https://llms-explorer.com/tree/wiredtiger-history-store-and-majority-commit-point-cache-pressure/ ## 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](https://jira.mongodb.org/browse/WT-3745) - 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](https://dba.stackexchange.com/questions/335254/mongodb-wiredtiger-history-store-file-growth-observed-during-failover) - 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](https://www.mongodb.com/docs/manual/tutorial/mitigate-psa-performance-issues.md) - 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](https://jira.mongodb.org/browse/WT-6681) - 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](https://www.mongodb.com/docs/manual/core/wiredtiger/) ## 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](https://www.mongodb.com/docs/manual/tutorial/mitigate-psa-performance-issues.md) - 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](https://www.mongodb.com/docs/manual/reference/read-concern-majority.md) - 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](https://jira.mongodb.org/browse/WT-18765) - 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](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) ## 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](https://source.wiredtiger.com/mongodb-4.4/arch-hs.html) - 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](https://source.wiredtiger.com/mongodb-4.4/arch-hs.html) - 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](https://netdata-website.netlify.app/guides/mongodb/mongodb-monitoring-checklist/) - 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](https://github.com/wiredtiger/wiredtiger/blob/develop/src/include/cache.h) ## 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](https://source.wiredtiger.com/mongodb-4.4/arch-hs.html) - 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](https://www.percona.com/blog/mongodb-101-how-to-tune-your-mongodb-configuration-after-upgrading-to-more-memory/) - 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](https://source.wiredtiger.com/mongodb-4.4/arch-hs.html) - 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](https://source.wiredtiger.com/mongodb-4.4/arch-hs.html) - 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](https://docs.percona.com/percona-monitoring-and-management/3/reference/dashboards/dashboard-mongodb-wiredtiger-details.html) - 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](https://www.netdata.cloud/guides/mongodb/mongodb-long-running-transactions/)