Details
-
Task
-
Resolution: Won't Fix
-
Major - P3
-
None
-
None
-
None
-
Fully Compatible
-
Sharding 2017-08-21
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.