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

Initial sync should do transaction table read with a later afterClusterTime

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 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

      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@mongodb.com Matthew Russotto
            Reporter:
            matthew.russotto@mongodb.com Matthew Russotto
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: