[SERVER-3767] Keep Indexes in Memory on Secondary Nodes Created: 06/Sep/11  Updated: 14/Sep/23  Resolved: 14/Sep/23

Status: Closed
Project: Core Server
Component/s: Index Maintenance, Performance, Replication
Affects Version/s: 1.8.2
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Mitchell Hashimoto Assignee: Backlog - Replication Team
Resolution: Duplicate Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-33352 Make the touch command work in WT sto... Closed
Assigned Teams:
Replication
Participants:
Case:

 Description   

Replica sets provide great automatic failover and redundancy, but the failover in any relatively high traffic database is almost useless since the secondaries don't seem to keep indexes or recently queried data in memory. We've solved this in the interim by writing a script with slaveok to query in the indexes and "warm the cache." I consider the fact this is necessary is ridiculous in a production server.

Could MongoDB secondaries please keep hot-data in memory so that in the case of a failover, page faults don't skyrocket. At the very least, indexes should always be kept in RAM.



 Comments   
Comment by Chris Harris [ 14/Sep/23 ]

This functionality was delivered via Mirrored Reads which are available beginning in version 4.4

Comment by Dwight Merriman [ 19/Sep/11 ]

typically the application of writes results in things being paged in. but under certain circumstances (such as a restart and few new writes) nothing would be there. might make sense for some queries to percolate through that say "touch this" or to prefetch from some indexes if file system cache is not full.

would be helpful to know how other databases have approached historically.

Generated at Thu Feb 08 03:03:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.