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

Initial sync should do transaction table read with a later afterClusterTime

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 6.1.0-rc0, 5.0.9, 4.4.15, 6.0.0-rc6
    • None
    • None
    • Fully Compatible
    • ALL
    • v6.0, v5.0, v4.4
    • Repl 2022-05-02, Repl 2022-05-16
    • 15

    Description

      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)

      Attachments

        Issue Links

          Activity

            People

              matthew.russotto@mongodb.com Matthew Russotto
              matthew.russotto@mongodb.com Matthew Russotto
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: