[SERVER-72489] Decide if catalog shards need ShardServerCatalogCacheLoader Created: 03/Jan/23 Updated: 04/Jan/24 Resolved: 10/Feb/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jack Mulrow | Assignee: | Jack Mulrow |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Sharding NYC 2023-02-06, Sharding NYC 2023-02-20 | ||||||||
| Participants: | |||||||||
| Description |
|
The purpose of the ShardServerCatalogCacheLoader (SSCCL) is to cache config server collection metadata in locally replicated collections. When a config server acts as a shard, it will already replicate the real metadata collections, so in theory using the SSCCL isn't necessary. There may be some work to ensure no shard components rely on side-effects of the SSCCL, but this may be less work than deciding how to handle the SSCCL when transitioning in and out of dedicated config server mode and prevents storing metadata twice on catalog shards. Currently, catalog shards use the ConfigServerCatalogCacheLoader, but we should further investigate and make a final decision. |
| Comments |
| Comment by Githook User [ 10/Feb/23 ] |
|
Author: {'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}Message: |