[SERVER-69754] Hedge the KeysCollectionCache refresh() with explicit local client Created: 15/Sep/22  Updated: 07/Nov/22  Resolved: 07/Nov/22

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

Type: New Feature Priority: Major - P3
Reporter: Andrew Shuvalov (Inactive) Assignee: Andrew Shuvalov (Inactive)
Resolution: Won't Fix Votes: 0
Labels: sharding-nyc-subteam2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Sharding NYC 2022-10-31, Sharding NYC 2022-11-14
Participants:
Story Points: 3

 Description   

In catalog shard mode, the key refresh will no longer use ShardLocal implementation underneath the keys loading machinery. The refresh() method will always first try to load keys explicitly remotely, and if the current cluster role is catalog shard (or config server), retry the keys loading locally.

CC tommaso.tocci@mongodb.com this is a good illustration (see PR) of how the refactoring works in general to support the catalog shard. Scroll to sharding_initialization.cpp change, the existing code is using the KeysCollectionClientSharded to access keys, and because underneath it's using Shard interface to read keys, it is using remote client when running on shards or mongs, and direct client on config.

After we refactor everything for catalog shard, the KeysCollectionClientSharded will be strictly remote, and KeysCollectionClientDirect strictly direct. At catalog shard the remote client will not work until the port is open, so the hedging with direct client will be triggered.

I am aware of the speed penalty, this will be fixed with different ticket using keys pre-loading at start, as described in design doc. This PR is 1/2 of the implementation outlined in design.


Generated at Thu Feb 08 06:14:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.