-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Replication
-
Fully Compatible
-
ALL
-
(copied to CRM)
During recovery oplog application we don't advance the oldest timestamp. This can pin a lot of data in the cache. Resulting symptoms include
- slow recovery due to resulting cache churn
- growth of lookaside (cache overflow) table and corresponding file WiredTigerLAS.wt
- in extreme cases cache-full hangs were observed. This was believed fixed with
SERVER-33191, but we should be alert for new occurrences of this issue.
- is duplicated by
-
SERVER-38698 Forgot to setOldestTimestamp when crash recovery in MongoDB 4.0
- Closed
- is related to
-
SERVER-38089 Fatal error 40292 due to missing oplog entry at the start time stamp
- Closed
- related to
-
SERVER-33191 Cache-full hangs on 3.6
- Closed
-
SERVER-34938 Secondary slowdown or hang due to content pinned in cache by single oplog batch
- Closed
-
SERVER-34941 Add testing to cover cases where timestamps cause cache pressure
- Closed
-
SERVER-35191 Stuck with cache full during rollback
- Closed
-
SERVER-35339 Complete recovery failure after unclean shutdown
- Closed
-
SERVER-36238 replica set startup fails in wt_cache_full.js, initial_sync_wt_cache_full.js, recovery_wt_cache_full.js when journaling is disabled
- Closed