Make donor shard's secondary pre-emptively refresh filtering cache asynchronously

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Incomplete
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • None
    • Sharding
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      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.

            Assignee:
            [DO NOT USE] Backlog - Sharding Team
            Reporter:
            Randolph Tan
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: