Open amnore opened 2 years ago
Hi @sciascid, @janlindstrom, and @ayurchen,
Regardless of the confusing claim on SI (see our discussion at https://github.com/codership/galera/issues/609), there seems no doubt that Galera prohibits the lost update anomaly https://galeracluster.com/library/training/tutorials/supporting-transaction-isolation-levels.html Any comment on this and the above anomaly found?
@sciascid, BTW, how's the improvement to the documentation going https://github.com/codership/galera/issues/609#issuecomment-1046763283 ?
Thanks!
Hi. If I understand it correctly, transactions issued on different nodes in a cluster should be protected from lost updates, as claimed in https://galeracluster.com/library/training/tutorials/supporting-transaction-isolation-levels.html. However, we have observed this anomaly in one of our tests.
We have set up our tests with the following configuration:
We run a cluster of two nodes using docker-compose (configuration). The versions are 10.7.3 for mariadb and 26.4.11 for galera. We are using a simple schema. There is only one table, each row containing only a key and a value:
We have one client for each node. First, we create the rows and initialize their values to 0. Then, the clients run a set of transactions generated by our test generator. The code for the clients can be found at galera.rs and cluster.rs. The values written by the clients are unique.
In one of our tests, there is a single row with key=0. We observed the following execution:
In this history, both T3 and T8 reads val=4. Then they proceed to overwrite this value and commit successfully. After that, T4 reads val=5, which means the write by T8 is lost.
This behavior seems to contradict the second example given in the documentation linked above, in which two transactions are issued on separate nodes, and one of them fails to commit because they try to update the same row. I can replicate this example when trying to follow it by hand using the test setup, though.
The tests can be run with the following steps:
Use verifier to verify the results
When a lost-update is found, the verifier will print something like this:
There are two transactions in the example. Transaction 6 reads (key=0, val=11) and writes (key=0, val=6). Transaction 2 reads (key=0, val=1) and writes(key=0, val=2).
This command will produce outputs like this:
![<W(0): 5>, <R(0): 5>]
is a transaction, and the prefix!
means it didn't commit successfully.In our tests, this phenomenon appears quite often (about 3 times in 10 runs), though the outputs of the verifier may differ.
Is this the expected behavior? Or am I missing something in the docs?