[SERVER-48446] Make donor shard's secondary pre-emptively refresh filtering cache asynchronously Created: 27/May/20  Updated: 06/Dec/22  Resolved: 29/Jul/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Randolph Tan Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-48456 Don't clear filtering metadata in sec... Closed
Assigned Teams:
Sharding
Participants:

 Description   

When secondaries perform refreshes today, it calls _flushRoutingTableCacheUpdates, waits for primary to refresh and the primary cache loader to write the new diffs to config.cache.chunks, wait for those writes to be replicated and then read the newly updated config.cache.chunks. However, this is not necessary in the donor shard since it already did the refresh as part of the migration.

The proposal is:
1. Update the config.cache.collection with the new shard version whenever donor shard successfully commits migration.
2. Intercept the update in the secondary and trigger an async task to preemptively reload without calling _flushRoutingTableCacheUpdates.



 Comments   
Comment by Kaloian Manassiev [ 28/May/20 ]

I think the write/update of config.cache.collection should happen as part of the recovery of the shardVersion, which is in CR now: https://mongodbcr.appspot.com/611950001/

Generated at Thu Feb 08 05:17:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.