Investigate in which cases can shard version convergence be slow due to the wait for configTime

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Done
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Catalog and Routing
    • CAR Team 2026-04-13
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      In the process of developing the new shard versioning protocol we overall agreed that waiting for the configTime would leave us in a position no worse than today where the secondary node has to issue a refresh on the primary and then wait for replication.

      However, we didn't fully explore all potential options and thus we can't tell if the following statements are fully true:

      • Will convergence of the secondary with the primary's state not be slower than today in regards to the shard version
      • Will we not be worsening overall the amount of time spent waiting
      • Is there any other scenario we haven't thought of that could lead to a slow convergence

            Assignee:
            Pol Pinol
            Reporter:
            Jordi Olivares Provencio
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: