Compare consistency models used in mgo

Question

MongoDB servers are queried with multiple consistency rules. In mgo, SetMode of the Session object changes the consistency mode for the session. Three types of consistency modes are available: Eventual, Monotonic, and Strong.

e.g.

session, err := mgo.Dial("localhost")
if err != nil {
    panic(err)
}
defer session.Close()
//Switch the session to a monotonic behavior.
session.SetMode(mgo.Monotonic, true)

I am reading about the different consistency models in https://en.wikipedia.org/wiki/Consistency_model

But what are the relations between the three models used in mgo?

Is it correct that Strong implies Eventual, and Eventual implies Monotonic?

Thanks.

Answer 1

These are the three consistency models that MongoDB claims to support:

• Strong consistency: All accesses are seen by all parallel processes (or nodes, processors, etc.) in the same order (sequentially).

• Monotonic reads: If a process reads the value of a data item x, any successive read operation on x by that process will always return that same value or a more recent value.

• Eventual consistency: If no new updates are made to a given data item, eventually all accesses to that item will return the last updated value.

By these definitions, Strong implies eventual, and strong implies monotonic, but there is no relation between eventual consistency and monotonic reads.

However, looking at the real system, there is more to be found.

In MongoDB, Monotonic mode means that the client opens a single connection to some secondary node. All reads happen through this connection. When a write happens, the client drops the connection and connects to the primary node, and then performs the write. Reads following a write are performed from the primary node.

In Eventual mode, reads are done from multiple secondary nodes, concurrently. This means that we might see updates out of order, as they reach different nodes. Writes are performed against the primary, but possibly in multiple concurrent connections. This means that writes may arrive out of order as well. It is not clear from the documentation if reads following the first write are all served by the primary, like in Monotonic mode, or if they continue to be served by secondaries. The source code, however, tells us that reads continue to be served by secondaries.

// Switch over a Monotonic session to the master.
if !slaveOk && s.consistency == Monotonic {
    s.slaveOk = false
}

Thus, for Mgo v2, Strong implies Monotonic implies Eventual.