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

Client sessions are not causally consistent for sharded metadata

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Sharding
    • Catalog and Routing
    • Sharding EMEA 2021-11-29, Sharding EMEA 2021-12-13, Sharding EMEA 2021-12-27
    • 0

    Description

      Gossiping the cluster time for causally consistent client sessions ensures causality for queries but it's not enough to ensure causality for sharded metadata operations.

      Scenario:

      • One client communicating with 2 routers A and B
      • Router A performs shardCollection on db.coll
      • Router B receives a query forĀ db.coll, refreshes from the CSRS with nearest read preference and read concern with minimum last known config time
      • The CSRS secondary serving the refresh still didn't replicate the config.collections entry for db.coll
      • Router B treats db.coll as unsharded collection

      At some point, router B will get to know that db.coll is sharded (e.g. after targeting the primary). However, gossiping the configOpTime and the topologyTime to the client would have allowed the second router to be causally consistent when refershing with afterClusterTime >= last known configOpTime.

      Attachments

        Activity

          People

            backlog-server-catalog-and-routing Backlog - Catalog and Routing
            pierlauro.sciarelli@mongodb.com Pierlauro Sciarelli
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated: