[SERVER-30088] Refresh the in-memory metadata cache on secondaries when invalidated by a primary metadata change Created: 11/Jul/17 Updated: 14/Jul/17 Resolved: 14/Jul/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding 2017-08-21 |
| Participants: |
| Description |
|
The current secondary behavior is just to invalidate the secondary's metadata so that the next request to the secondary causes an in-memory refresh. Refreshes require contacting the shard primary, in case the primary is not up to date either and must refresh from the config servers. A secondary that has the up to date metadata persisted, but hasn't serviced requests in a long while so the up to date metadata hasn't been loaded into memory, can get stuck when it receives a request while either there is no primary or the primary cannot be contacted. To alleviate this situation, we will proactive reload the in-memory cache on receipt of metadata updates. This is a performance improvement. |
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 14/Jul/17 ] |
|
Closing as won't fix. We decided to do |