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

Consider making refresh on shards synchronous in the create collection coordinator

    • Type: Icon: Task Task
    • Resolution: Works as Designed
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Catalog and Routing
    • v8.0
    • CAR Team 2024-04-15
    • 41

      Before SERVER-80135, upon shard collection, the filtering information would be cleared on all non-db-primary participant shards and either installed correctly or cleared on the dbPrimary. In SERVER-80135, this behavior was changed so that the filtering information would be cleared on all participants (including the dbPrimary) and a best effort, asynchronous refresh would be done after the release of the critical section.

      The motivation behind this was that when creating a collection on a shard outside the dbPrimary, it seemed like strange behavior to have the filtering information known on the dbPrimary but not on the shard owning data. The refresh was made asynchronous because it was best effort anyways.

      However, we are seeing many test failures due to shards not knowing their filtering information after the shardCollection completes. Additionally, this new behavior could increase the latency of the first operation after the shard collection which would now have to wait for the refresh to finish rather than that cost being included in the shardCollection command.

      In team discussions, it seemed as though the leaning was towards simply making the refresh on all shards synchronous so that the behavior is more consistent with prior versions. In this ticket, we should ensure that we have a consensus on this behavior and update the refresh if needed.

            Assignee:
            marcos.grillo@mongodb.com Marcos José Grillo Ramirez
            Reporter:
            allison.easton@mongodb.com Allison Easton
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: