InitializePlacementHistoryCoordinator must drain any operation on the global catalog before generating its materialized view

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.3.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Catalog and Routing
    • Fully Compatible
    • CAR Team 2025-08-18, CAR Team 2025-09-01, CAR Team 2025-09-15, CAR Team 2025-09-29, CAR Team 2025-10-13
    • 🟥 DDL
    • None
    • None
    • None
    • None
    • None
    • None

      Today, the initialization of config.placementHistory is implemented through a ShardingCatalogManager method that provides limited resilience to step down events of the config server and ability to serialize with incompatible operations - namely:

      1. Targeting queries from change stream readers (addressed through SERVER-108996)
      2. Commit of DDL operations & topology changes (addressed through SERVER-108998)
      3. Commit of chunk migrations (still pending)
      4. Removal of disposable documents of {{config.placementHistory }}(addressed through SERVER-108986)

      The InitializePlacementHistoryCoordinator introduced with SERVER-108943 is meant to close the gap.

       

      The objective of this ticket is to solve any data race that is still unaddressed and set the value of initializationTime in conditions of full isolation, while minimizing the time of contention of other operations.

            Assignee:
            Paolo Polato
            Reporter:
            Paolo Polato
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: