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

Config Shard calls do not enforce causal consistency access for local shards

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • None
    • Catalog and Routing
    • ALL
    • CAR Team 2024-01-22

    Description

      Calls to the config shard right now are done via the help of ShardRegistry::getConfigShard() which returns a ConfigShardWrapper instance. This wrapper is in charge of attaching the configTime to the requests sent to the config server.

      However, the approach chosen is flaky since the causal consistency expected here is not enforced and instead offered as a best-effort. This is because the code uses the minClusterTime setting in the ReadConcernPreferences. This is exclusively used for choosing which node to route the request to but is ignored if no node satisfies it (code that does this).

      This means that theoretically if the wrong node is chosen it could be reading stale data if they do not set a valid readConcern clusterTime.

      This is currently the case if the node chosen is a stale secondary accessing itself via the RSLocalClient as part of ShardLocal.

      Attachments

        Activity

          People

            backlog-server-catalog-and-routing Backlog - Catalog and Routing
            jordi.olivares-provencio@mongodb.com Jordi Olivares Provencio
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

              Created:
              Updated: