Context

We refer to "global catalog" as the set of collections stored in the config server that contains housekeeping metadata (not user data) necessary to run a sharded cluster. E.g. collections like (config.collections, config.shards etc...).

When reading from global catalog, we need to guarantee casual consistency with correlated read/write operation that happened previously on the global catalog.

This is ensured by attaching afterClusterTime: configTime read concern to all the reads that target the global catalog. Using this afterClusterTime is one of the foundamental pieces on which built the catalog consistency model. So it is increadibly important.

Problems

• The logic that attach afterClusterTime on global catalog is scattered around:
  • For finds, we use Shard::exahustiveFindOnConfig()
  • For aggregations (e.g. ShardingCatalogClient::runCatalogAggregation) we defer the responsibility to the caller  (e.g. here)
• The logic is placed in files that are not owned by CAR team (e.g. shard_remote.cpp)
  • So the risk is that this logic is modified by another team without CAR approval.

Proposal

Expose a ShardingCatalog API that provides clear causal consistency guarantees.