setFCV waits on wrong opTime to be majority committed if it performs no writes

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: 7.0.0, 8.0.0, 8.3.0-rc0, 8.2.0
    • Component/s: Upgrade/Downgrade
    • None
    • Catalog and Routing
    • ALL
    • 200
    • 1
    • 🟩 Routing and Topology
    • None
    • None
    • None
    • None
    • None
    • None

      The setFCV command explicitly waits for majority write concern after it runs. It is known that waiting for majority is problematic if the operation did not perform any writes (it will wait on a very old opTime), see SERVER-56556, SERVER-71305, SERVER-108811.

       

      In setFCV we already have workarounds for an already fully upgraded/downgraded cluster and for dryRun. However there are other ways in which setFCV can run without performing any writes, for example when a shard runs the "prepare" phase it does not do any metadata changes nor updates the FCV document.

       

      We should solve this problem in a generic way. Possibly we can always call setLastOpToSystemLastOpTime before waiting for majority, since setFCV's results should always be based on majority written data even if it did not write anything.

            Assignee:
            Unassigned
            Reporter:
            Joan Bruguera Micó
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: