Implement shard version mismatch resolution for authoritative collections

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Catalog and Routing
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      In order to enable support of authoritative collections we have to handle the case of having an authoritative CSS.

      In order to do this the following protocol has to be followed:

      • If the versions are comparable then we use that information to determine if the router is stale
      • Otherwise, if the router is more recent than us, or if the versions can’t be compared:
        • We wait until the shard’s version matches the router’s
        • OR we wait until the shard has replicated up to the configTime received and it is majority available, whichever of these two events come first
        • Once we’re done waiting, we compare against the current state and if it’s a mismatch then the router is guaranteed to be stale

      The comparison checks must also consider a critical section not being present as otherwise we'd be making comparisons mid-way through a change in the CSS.

      Note that we must also handle the case of a CSS becoming non-authoritative by the time we finish the wait, in which case we should fallback to the handling done by non-authoritative CSS

            Assignee:
            Unassigned
            Reporter:
            Jordi Olivares Provencio
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: