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

readConcern afterClusterTime not working in a non-sharded replica set

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • Labels:
      None
    • Sharding
    • ALL
    • Hide

      1. Create a standard replica set
      2. Insert a document and record the operationTime from the response
      3. Attempt to find that document on a secondary with a readConcern containing afterClusterTime whose value is the operationTime from the insert response

      Expected results: the find command succeeds and returns the requested document

      Actual results: the secondary returns this error: readConcern afterClusterTime must not be greater than clusterTime value", "code" : 72, "codeName" : "InvalidOptions"

      Show
      1. Create a standard replica set 2. Insert a document and record the operationTime from the response 3. Attempt to find that document on a secondary with a readConcern containing afterClusterTime whose value is the operationTime from the insert response Expected results: the find command succeeds and returns the requested document Actual results: the secondary returns this error: readConcern afterClusterTime must not be greater than clusterTime value", "code" : 72, "codeName" : "InvalidOptions"

      According to the design doc for causal consistency a non-sharded replica set should still honor afterClusterTime even in the absence of $clusterTime gossiping.

      But in read_concern.cpp there is a check that the logical clock has advanced to afterClusterTime which is performed before waiting for that cluster time to replicate through the oplog.

      The result is that readConcern.afterClusterTime fails consistently on secondary members of replica sets that are not part of a sharded cluster, but succeeds when part of a sharded cluster.

            Assignee:
            backlog-server-sharding [DO NOT USE] Backlog - Sharding Team
            Reporter:
            jeff.yemin@mongodb.com Jeffrey Yemin
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: