Quantcast
Channel: MySQL Forums - NDB clusters
Viewing all articles
Browse latest Browse all 1560

missing row form select for update (no replies)

$
0
0
Hello,

I observed unexpected behavior while using "Select for Update" in the case of a NDB cluster.

Versions are: mysql-5.7.26 and ndb-7.6.10

Topology is 4 ndbd(NDB) nodes, 4 mysqld(API) nodes, 2 ndb_mgmd(MGM) nodes.

We are performing concurrent "select for update" (SFU) on a table. These concurrents SFU are done through different MySQL node (like 1 and 3).

Behavior observed is:
T+0ms-System ok
T+35ms-Node1-Issue select for update
T+62ms-Node3-Issue select for update
T+67ms-Node1-Return the 4 matching row - As expected
T+67ms-Node1-Execute update on one of the matching row
T+70ms-Node1-Update successfully done
T+77ms-Node3-Return only 3 matching row - The row just updated is missing !!!
T+77ms-Node3-Update another matching row
T+81ms-Node3-Update successfully done on the other the matching row

Is it expected that
* the cluster "blocks" until the update on the first node ? (for us yes)
* the cluster return only 3 row, excluding the update row ? (for us no, it should contain the four row, with last update data)

Could it be due that we are issuing the concurrent "Select for update" from different MySQL nodes ?

Here, the total duration is around 50ms and the total number of rows for this table is very small, about 1660 rows.

As additionnal information:
*the "where" is not on the primary key but on column contained in a single multi-column index
* the "select" part contains a single column which is part of the multi-column index used in the where clause.

Could some please advise ?

Viewing all articles
Browse latest Browse all 1560

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>