We already know that the zookeeper, a write request forwarded to the leader, the read request follower deal with their own, no sync situation issued less than linearizability. ? Mongodb official document it says so, "MongoDB is consistent by default: reads and writes are issued to the primary member of a replica set."
This sentence misled me for many years, so I always thought that by default, read and write operations are distributed to primary, which should always be linearizable, right? Results after finding out the truth let my tears fall.
Write Concern，Read Concern和Read Preference
Mongodb provides flexible consistency, because it can set a different Write Concern, Read Concern and Read Preference.
Write Concern decided to confirm the level of write operations on the database, such as whether most successful node writes only returned to the client confirmed.
Read Concern decided to return isolation level data read operation, such as whether the most successful data nodes Hill returned to the read operation.
Read Preference determines the read operation from which node.
By default
In mongodb version 4.0, the default Read Preference is primary, that is, read and write operations are sent to the primary.
The default Write Concern is w: 1, for the replica set, it is confirmed that as long as the primary written on it. So you think you write succeeded, but not before the primary data handed out and hung up, then the success of the data that you write, disappeared without a trace. The default Read Concern it? Actually local! So you read data from a primary x, when x has not been distributed primary hung up, no new primary information x, then again when reading data from the new primary, then x it seems to have never existed the same.
So, by default, consistency mongodb and Linearizability even close.
Majority
Write Concern that the Read Concern and the majority are set to what will happen?
Majority of Write Concern refers to the re-confirmation of data distributed to most members of the replica set.
Majority of Read Concern refers to the read data is confirmed by the majority of members of the replica set.
Imagine the following situation:
N1 is the primary replica set, N2 and N3 are two secondary. Read and write requests are sent to the client S1 N1.
Suddenly isolation network N1, and not N2, N3 of the communication.
N2 was elected as the primary, but knew nothing N1, still think of themselves as primary, so in this case a copy of the episode actually has two primary.
S2 client to write new data to the Write Concern majority of N2.
After the data is written N2 N3, S2 to be written back to the confirmation.
S1 majority of clients to read data from the Read Concern N1.
It is easy to see, in this case of no linearizability.
In fact, Mongodb there is one kind of situation worse, N1 and N2 at the same time as the primary time, S1 is possible to write the request to the N2, read request to the N1. It is written so that even their own data could not be read. Mongodb because the driver generally requires a connection pool, but there mongodb Read Preference options to achieve this separate read and write, it is very troublesome to implement. In addition to the official driver, as well as maintenance of the open source community, did not notice these details, then, it is prone to this problem.
And early in mongodb, did not give you the opportunity to detect the stale primary. . .
https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#using-setversion-and-electionid-to-detect-stale-primaries
Linearizable Read Concern
Linearizable Read Concern is mongodb 3.4 appear in order to solve the above problems. With linearizable of Read Concern, can finally read a copy of the latest data centralization friends. Linearizable Read Concern There are some restrictions on the use of:
It can only be used in the read operation of the primary
Query must uniquely identify a document
The principle linearizable Read Concern is before the read operation added an empty write operation, if the current primary is stale, empty the write operation will fail, to be checked out. In fact zookeeper and the sync exactly the same the same thing.
Causal Consistency
In the above example, the read-write client are sent to the primary, but always make secondary idle is not very good, it is better to put forward a separate read and write.
However, separate read and write from the beginning was prone to problems:
N1 is the primary replica set, N2 and N3 are two secondary.
S client settings Read Preference, allows read requests to the secondary, the write request to the primary.
S in the Write Concern majority N1 to write the order data x.
After the x N1 distributed to N2, more than half a determination to return to success.
S x read on the N3, we found no such orders.
It was very embarrassing, to write their own data, do not see themselves. So mongodb 3.6 adds Causal Consistency consistency.
To achieve it, mongodb each node needs to be able to get the correct time. Clock is a very important part of a distributed system, in other articles we will highlight.
Now mongodb works like this:
N1 is the primary replica set, N2 and N3 are two secondary.
S client settings Read Preference, allows read requests to the secondary, the write request to the primary.
S in the Write Concern majority N1 to write the order data x, recording time T.
After the x N1 distributed to N2, more than half a determination to return to success.
S x in the read N3, with T as the parameter reading operation.
N3 no operating time T, began to wait.
X N3 get data from the N1, N3 means that the data have T time.
N3 data back to S.
In order to achieve Causal Consistency, mongodb the client needs to do something extra, such as open client session, as well as a corresponding number of restrictions, such as only one thread at a time to perform the operation in the client session.