Initial sync should do transaction table read with a later afterClusterTime

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 5.0.9, 4.4.15, 6.0.0-rc6, 6.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • v6.0, v5.0, v4.4
    • Repl 2022-05-02, Repl 2022-05-16
    • 15
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      To find the beginFetching and beginApplying timestamps in logical initial sync, we do a three-step process

      1) Read the last optime on the sync source.

      2) Read the transaction table on the sync source

      3) Read the last optime on the sync source again.

      beginApplying is the result of the third step. beginFetching is either the result of the first step or a time in the transaction table. We must read the transaction table strictly after that everything before that last optime in the first step. On a primary sync source, that just means the no-holes point, which we achieve by using an afterClusterTime of (0,1). On a secondary sync source, after SERVER-58636, that means the lastAppliedSnapshot must reach that point. We can achieve that by instead using an afterClusterTime that is the result of 1).

      Additionally, we need to make sure everything after 3) is read after the lastApplied reaches the beginApplyingTimestamp. Fortunately we already do this by using an afterClusterTime of the beginApplyingTimestamp in the next query (for FCV)

            Assignee:
            Matthew Russotto
            Reporter:
            Matthew Russotto
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: