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.