Make cloneAuthoritativeMetadata DDL avoid holding the critical section when cloning metadata

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.3.0-rc0
    • Affects Version/s: 8.3.0-rc0
    • Component/s: None
    • None
    • Catalog and Routing
    • Fully Compatible
    • CAR Team 2025-09-01, CAR Team 2025-09-15, CAR Team 2025-09-29
    • 200
    • 🟦 Shard Catalog
    • None
    • None
    • None
    • None
    • None
    • None

      The cloneAuthoritativeMetadata DDL is a hook that runs in the background during an FCV upgrade. Its purpose is to clone database metadata from the global catalog (config.databases on the config server) to the shard catalog (config.shard.catalog.databases on the shard server), thereby making the shard’s database metadata authoritative.

      During the FCV upgrade transition, however, the shard server is not yet authoritative. The database metadata stored there is considered lazy authoritative, meaning it may or may not exist. The protocol is pessimistic.

      Therefore, we can safely clone the metadata (transactionally, per database) without holding the critical section. This avoids blocking reads and writes, even briefly, for unsharded collections.

      Note: The implementation must add an exception to bypass the current mechanisms that enforce filtering of database metadata on the shard. This is necessary because the components that manage this information (DSR — DatabaseShardingRuntime, and DSMA — DatabaseShardingMetadataAccessor) currently do not allow installing metadata without the critical section.

            Assignee:
            Pol Pinol
            Reporter:
            Pol Pinol
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: