[SERVER-41923] Provide a way for a secondary to warm up the cache automatically by matching the cached data on the primary Created: 26/Jun/19 Updated: 27/Oct/23 Resolved: 10/Jan/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Dmitry Ryabtsev | Assignee: | Backlog - Replication Team |
| Resolution: | Gone away | Votes: | 1 |
| 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 |
|
Right now if a replica set (shard) member is restarted it brings a performance impact since the members has to load data into the cache from the disk before the performance returns to the normal level. The only workaround for that so far is by synthesizing a custom workload that would warm up the cache for the users ad-hoc. This presents the problem as it would require certain development effort and, for instance, in Atlas the failovers (restarts) are pretty frequent phenomenon due to the maintenance activities. It would be great if the secondary could get the map of the cached data from another member (say, primary) and use it to warm up its own cache. |
| Comments |
| Comment by Kelsey Schubert [ 10/Jan/22 ] |
|
This feature was tracked over a number of tickets and is available starting in MongoDB 4.4.0. For more details, see https://docs.mongodb.com/manual/release-notes/4.4/#mirrored-reads |
| Comment by Siyuan Zhou [ 11/Jul/19 ] |
|
Reopened the ticket as the proposal of |
| Comment by Siyuan Zhou [ 11/Jul/19 ] |
|
Closing this ticket as a dup of |