Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-38504

On Primary, to verify that our lastAppliedOpTime is lagged behind the TopologyCoordinator::_lastCommittedOpTime, we should compare both its term and timestamp for pv1.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Won't Fix
    • Affects Version/s: 3.6.9
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Operating System:
      ALL

      Description

      Consider the below upgrade->downgrade->upgrade (pv1->pv0->pv1 ) sequence.

      1) Start a replica set in pv1.

      2) Insert some document in pv1 (for term =1)

      3)Downgrade to pv0 while the secondaries are still replicating the documents from previous pv1 (term =1)

      4) Upgrade to pv1 before the secondaries downgrade to pv0 and their lastDurableOptime are still in term 1.

      5) The current primary when it attempts to write in its current term (i.e.) term 0,  it does below 2 things

             - Moves forward its lastAppliedOpTime.

             - Sets the new lastAppliedOpTime to its stableOpTime only if the new lastAppliedOpTime <= lastCommitedOpTime.

      Currently if both the lastAppliedOpTime and lastCommitedOpTime are from pv1, we first compare its term and if they are equal, then we compare its timestamp. In the above the sequence, say our lastCommitedOpTime is  (ts1, t:1) and lastAppliedOpTime is (ts2, t:0) where ts1 < ts2. This means we would satisfy the above condition lastAppliedOpTime <= lastCommitedOpTime that results in updating our stableTimestamp. As a result, it leads to invariant failure in line 3398.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              backlog-server-repl Backlog - Replication Team
              Reporter:
              suganthi.mani Suganthi Mani
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: