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

Operations on new clients get latest in-memory clusterTime as operationTime

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0, v3.6
    • Sprint:
      Sharding 2018-06-18
    • Linked BF Score:
      60

      Description

      When computing operationTime for a response, the "client operation time" at the start of a command is compared to the time at the end. There are some error contexts where there is no start operation time, so if the start time is a null logical time, the latest in-memory cluster time is returned.

      The start time is computed by getting the opTime of the last op on the current client. If a client hasn't been used before though, this can be null, which results in a null start time and the returned operationTime will be the latest in-memory time, even for successful operations.

      This does not violate causal consistency, but it can create problems in our test infrastructure when the no-op writer is off, because it's possible the latest in-memory clusterTime is a higher than the latest opTime in a replica set primary's oplog. In particular, when secondaries force metadata refreshes on the primary, they use the operationTime of _forceRouterConfigUpdate to do a waitUntilOpTime (which bypasses forced no-op writes) and can hang forever.

      Possible solutions would be:

      • Distinguishing between not having a start time at all and running on a new client (possibly with a boost::optional or new sentinel logical time value)
      • Changing computeOperationTime to return the lastAppliedOpTime instead of the latest in-memory time when there is no start time
      • Using the lastAppliedOpTime as the start client operation time if the client has no last op

      This is new behavior introduced by the refactoring in SERVER-34843. It also exacerbates SERVER-31887, since successful requests can receive an operationTime not in the primary's oplog.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              misha.tyulenev Misha Tyulenev
              Reporter:
              jack.mulrow Jack Mulrow
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: