Learning records of mongodb master class (day 18)


Eighteenth days

The chapter to be learned today is “21 transaction development: read operation transaction II”. Continue with yesterday’s topic. Yesterday, we talked about where to read the readpreference, and today, we talked about what kind of data readconcert to read.

What is readconcert?

After the specified node is selected by readpreference, readconcert determines which data on this node is readable, similar to the isolation level of the relational database. Optional values include:

  • Available: read all available data;
  • Local: read all available data belonging to the current partition. This is the default value;
  • Major: read the data submitted on most nodes;
  • Linearizable: can read documents linearly;
  • Snapshot: read the data in the latest snapshot, which is described in Chapter 3;

Readconcert: local and available

Learning records of mongodb master class (day 18)
There is no difference between local and available in a replica set. The difference between them is mainly reflected in the fragmentation. Consider the following scenarios:

  • A chunk x is migrating from shard1 to shard2;
  • In the whole migration process, some data in chunk x will exist in shard1 and shard2 at the same time, but shard1, the source fragment, is still the responsible party of chunk X:
  • All the read and write operations to chunk x still enter shard1;
  • The information chunk x recorded in config still belongs to shard1;
  • If you read shard2, the difference between local and available will be reflected:
  • Local: only the data that shard2 should be responsible for (excluding x);
  • Available: what to read in shard2 (including x);

Readconcert: local and available

matters needing attention:

  • Although it seems that you should always choose local, filtering the result set will cause additional consumption. In some unimportant scenarios (such as statistics), available can also be considered;
  • Mongodb < = 3.6 does not support the use of {readconcert: “local”} for slave nodes;
  • When reading data from the master node, the default readconcertn is local, and when reading data from the slave node, the default readconcertn is available (forward compatibility reason).

readConcern: majority

To put it bluntly, only after more than half of the node data has been submitted successfully can it be read out
Learning records of mongodb master class (day 18)

Readconcert: the way to realize the major

Learning records of mongodb master class (day 18)
Consider secondary1 at T3, where:

  • It will return x = 0 for the read operation that requires the majority;
  • For a read operation that does not require major, it will return x = 1;

How to achieve it?
Multiple x versions are maintained on the node, mvcc mechanism
Mongodb links different versions by maintaining multiple snapshots:

  • Each version confirmed by most nodes will be a snapshot;
  • The snapshot will not be deleted until no one uses it;

Experiment: readconcert: “major” vs “local”

  • Install the 3-node replica set.
  • Note the server parameter enablemajorityreadconcert in the configuration file

Learning records of mongodb master class (day 18)

  • Lock two slave nodes in the replica set with DB. Fsynclock() (simulate synchronization delay)

Readconcert verification

  • db.test.save({“A”:1})
  • db.test.find().readConcern(“local”)
  • db.test.find().readConcern(“majority”)
  • Execute dB. Fsyncunlock() on a slave node
  • Conclusion:
  • Using the local parameter, you can directly query the write data
  • With major, only data that has been confirmed by most nodes can be queried
  • Update and remove and the same

Readconcern: major and dirty reading

This is actually the same as Oracle’s transaction
Rollback in mongodb:

  • Write operations are unsafe before reaching most nodes. Once the master node crashes and the slave node has not been copied to the operation, the previous write operation is lost;
  • Consider a write operation as a transaction. From the perspective of transaction, it can be considered that the transaction has been rolled back.

Therefore, from the perspective of distributed system, the transaction submission is promoted to multiple node level “submission” of distributed cluster, rather than “submission” on a single node.
Consider dirty reads when rollback is possible:

  • If a write operation is read before it reaches most nodes, and then the operation is rolled back due to system failure, a dirty read problem occurs;

Using {readconcert: ‘priority’} can effectively avoid dirty reads

Readconcert: how to realize safe read-write separation

Learning records of mongodb master class (day 18)
Consider the following scenarios:

Write a piece of data to the master node;
Read this data immediately from the slave node.

How to ensure that you can read the data just written?

The order just written may not be read in the following way

db.orders.insert({ oid: 101, sku: ”kite", q: 1})

Use writeconcert + readconcert priority to solve

db.orders.insert({ oid: 101, sku: "kiteboar", q: 1}, {writeConcern:{w: "majority”}})

readConcern: linearizable

Read only the data confirmed by most nodes. The biggest difference between them is to ensure the absolute linear order of operations. The reading occurring after the natural time of the write operation must be able to read the previous writing

  • Only valid when reading a single document;
  • It may lead to very slow reading, so it is always recommended to use maxtimems together;

Learning records of mongodb master class (day 18)

readConcern: snapshot

{readconcern: ‘snapshot’} only works in multi document transactions. The readconcert of a transaction
Set to snapshot to guarantee read in the transaction:

  • No dirty reading;
  • No non repeatable reading;
  • There is no unreal reading.

Because all reads will use the same snapshot, the snapshot will not be released until the transaction is committed.

Readconcert: summary

  • Available: read all available data
  • Local: read all available data belonging to the current partition, the default setting
  • Major: sufficient guarantee of data read consistency, maybe you need to pay attention to the most
  • Linearizable: enhanced handling of exceptions when the primary node is out of contact in the case of major
  • Snapshot: highest isolation level, close to seriazable

Recommended Today

Ruby process control method

In this chapter, we will discuss more Ruby process control case As we can see, this is quite close to the switch of C and Java, but it is more powerful ruby> i=8 ruby> case i     | when 1, 2..5     |   print “1..5\n”     | when 6..10     |   print “6..10\n”     | end 6..10    nil  2.. 5 represents a range from 2 to 5. The following expression tests if I […]