[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: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Participants: | |||||||||
| Case: | (copied to CRM) | ||||||||
| 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. |