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

Freshly synced secondaries respond to queries before their "sync time"

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Works as Designed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Replication
    • Labels:
      None
    • Operating System:
      ALL
    • Backport Requested:
      v3.6

      Description

      The last phase of a secondary performing initial sync is to apply oplog operations up through some time `T` representing when the collection cloning phase completed. It's incorrect for a secondary to respond to majority read/at a timestamp queries before time T.

      When a secondary comes out of initial sync, it will still have a notion of the replica sets majority commit time. Because the majority commit time is translated to a "read at a timestamp", the secondary will incorrectly respond to a query, but with a view of inconsistent data.

      A couple starting points for solutions:

      1. An API was introduced for recover to a stable timestamp known as the "initial data timestamp" that replication sets when initial sync completes. This represents the timestamp at which the data is in a consistent state. This could be used to reject/block incoming majority reads/read at a timestamp requests.
      2. Alternatively, a secondary can refuse to come out of initial sync until the majority commit point passes `T`. Currently there is no mechanism to tell drivers which timestamps a node can service reads for. This solution would be a way to signal to drivers to not send majority reads the node cannot service, at the cost of not participating in reads `>= T`.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              backlog-server-repl Backlog - Replication Team
              Reporter:
              daniel.gottlieb Daniel Gottlieb
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: