Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-84243

Dedicate a catalog cache and loader to the shard role

    • Catalog and Routing
    • CAR Team 2024-01-08, CAR Team 2024-01-22, CAR Team 2024-02-05, CAR Team 2024-02-19, CAR Team 2024-03-04, CAR Team 2024-04-15, CAR Team 2024-10-14, CAR Team 2024-10-28, CAR Team 2024-11-11, CAR Team 2024-11-25, CAR Team 2024-12-09
    • 0
    • 3

      Today, MongoD uses a single CatalogCache and CatalogCacheLoader for both it's shard-role responsibilities (i.e., updating the filtering metadata) and its bespoke router-role support (i.e., routing cross-shard $lookup queries).

      As we give MongoD a proper routing support equivalent to the routing facilities MongoS provides, we want to allow the routing layer to use a separate CatalogCache that is backed by a ConfigServerCatalogCacheLoader (CSCCL), so that routing operations do not need to stall waiting for replication. However, the shard-role use of the CatalogCache needs to continue to use CatalogCache backed by ShardServerCatalogCacheLoader (SSCCL), to ensure that the routing table view is consistent between primaries and secondaries on refresh.

      To achieve this goal, we'll support two CatalogCache and CatalogCacheLoader instances in each MongoD: one used for routing, and the other for shard-role activities. The use of the shard-role implementation should be very limited (essentially, only to filtering metadata updating). To implement this, we'll introduce a new CatalogCacheAndLoaderBackingShardRole object that encapsulates the shard-role state, and clarify that the CatalogCache available on the grid should be used exclusively for routing.

            Assignee:
            pol.pinol@mongodb.com Pol Pinol
            Reporter:
            george.wangensteen@mongodb.com George Wangensteen
            Votes:
            0 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: