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

Support causal consistency with secondary reads in sharded, replicated MongoDB clusters

    • Type: Icon: New Feature New Feature
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.5.12
    • Affects Version/s: None
    • Component/s: Replication, Sharding
    • Labels:
    • Fully Compatible
    • Sharding 2017-07-31, Sharding 2017-08-21

      Successive reads by a single client may be satisfied by different mongod nodes, due to chunk migration or when the client has allowed reads from replica set secondaries. Because these different mongod nodes have independent notions of time in the case of different shards, or may have replicated to different points in the oplog in the case of replica set secondaries, clients may be able to observe causal inconsistencies if they take no application-specific precautions, such as pinning connections to specific mongod nodes.

      MongoDB could provide an application independent system for enforcing causal consistency by passing clock tokens – vector or lamport clock values that could be passed among mongodb nodes and clients. In a single replica set, the new "readConcern:

      { after: <OpTime> }

      " could be used in combination with $replData metadata to ensure that successive reads used optimes at least as new as the optime of the most recent read or write a client was aware of. In sharded systems, a vector of such optimes, or some other token, could be used instead.

            misha.tyulenev@mongodb.com Misha Tyulenev (Inactive)
            schwerin@mongodb.com Andy Schwerin
            0 Vote for this issue
            17 Start watching this issue