Description:
Hello, I found a bug in 8.0.35-cluster version of MYSQL cluster. It will cause "error 499".
The detail is as follow. It need at least 4 nodes.
Node 1:
Poc:
```
update mytest100.test6 set
column1 = cast(coalesce(mytest100.test6.column4,
mytest100.test6.column3) as float),
column2 = case when EXISTS (
select ref_19.column2 as c0,
ref_19.column59 as c1,
mytest100.test6.column4 as c2,
ref_20.column2 as c3
from
mytest100.test7 as ref_19
inner join mytest100.test4 as ref_20
on (true)
where ref_19.column1 is NULL
limit 13) then mytest100.test6.column4 else mytest100.test6.column4 end
;
```
result:
```
1713655678.495958 to 1713655679.821072 received:mysql_store_result() failed:Lock wait timeout exceeded; try restarting transaction
```
Node 2:
Poc:
```
update mytest100.test6 set column2 = mytest100.test6.column4;
```
result:
```
1713655678.494852 to 1713655679.826581 received:mysql_store_result() failed:Got temporary error 499 'Scan take over error, restart scan transaction' from NDBCLUSTER
```
Node 3:
Poc:
```
UPDATE mytest100.test6 SET column2 = 31.84, column3 = 63.81, column4 = 94.55 WHERE ((column2 > NULL) OR column1 < 18.93) AND column1 < 11.61;
```
result:
```
1713655678.498583 to 1713655679.838596 received:Query executed successfully, but no result set was returned.
```
Node 4:
Poc:
```
UPDATE mytest100.test6 SET column1 = 97.34, column2 = 74.85, column4 = 90.49 WHERE (column2 > NULL) OR column3 < 63.94;
```
result:
```
1713655678.476508 to 1713655678.548571 received:Query executed successfully, but no result set was returned.
```
This bug requires injecting pocs from node1 to node3 at the same time as node4's poc is executing, and if a lock timeout can be triggered, there is a high probability that the bug will be reproduced.
Architecture Information:
'''
[NDBD DEFAULT]
NoOfReplicas =2
DataMemory = 512M
IndexMemory = 64M
[NDB_MGMD]
NodeId=1
hostname =192.172.10.8
datadir =/var/lib/mysql-cluster
[NDBD]
NodeId =2
hostname =192.172.10.9
datadir =/usr/local/mysql-cluster/data
NodeGroup=0
[NDBD]
NodeId =3
hostname =192.172.10.10
datadir =/usr/local/mysql-cluster/data
NodeGroup=1
[NDBD]
NodeId =4
hostname =192.172.10.11
datadir =/usr/local/mysql-cluster/data
NodeGroup=0
[NDBD]
NodeId =5
hostname =192.172.10.12
datadir =/usr/local/mysql-cluster/data
NodeGroup=1
[mysqld]
NodeId =6
hostname =192.172.10.9
[mysqld]
NodeId =7
hostname =192.172.10.10
[mysqld]
NodeId =8
hostname =192.172.10.11
[mysqld]
NodeId =9
hostname =192.172.10.12
'''
How to repeat:
导入我提供的data文件，然后按一定次序执行poc，就可以复现。
Suggested fix:
It looks like there is a problem with the scanning part of update, possibly related to the temp table.
Description: Hello, I found a bug in 8.0.35-cluster version of MYSQL cluster. It will cause "error 499". The detail is as follow. It need at least 4 nodes. Node 1: Poc: ``` update mytest100.test6 set column1 = cast(coalesce(mytest100.test6.column4, mytest100.test6.column3) as float), column2 = case when EXISTS ( select ref_19.column2 as c0, ref_19.column59 as c1, mytest100.test6.column4 as c2, ref_20.column2 as c3 from mytest100.test7 as ref_19 inner join mytest100.test4 as ref_20 on (true) where ref_19.column1 is NULL limit 13) then mytest100.test6.column4 else mytest100.test6.column4 end ; ``` result: ``` 1713655678.495958 to 1713655679.821072 received:mysql_store_result() failed:Lock wait timeout exceeded; try restarting transaction ``` Node 2: Poc: ``` update mytest100.test6 set column2 = mytest100.test6.column4; ``` result: ``` 1713655678.494852 to 1713655679.826581 received:mysql_store_result() failed:Got temporary error 499 'Scan take over error, restart scan transaction' from NDBCLUSTER ``` Node 3: Poc: ``` UPDATE mytest100.test6 SET column2 = 31.84, column3 = 63.81, column4 = 94.55 WHERE ((column2 > NULL) OR column1 < 18.93) AND column1 < 11.61; ``` result: ``` 1713655678.498583 to 1713655679.838596 received:Query executed successfully, but no result set was returned. ``` Node 4: Poc: ``` UPDATE mytest100.test6 SET column1 = 97.34, column2 = 74.85, column4 = 90.49 WHERE (column2 > NULL) OR column3 < 63.94; ``` result: ``` 1713655678.476508 to 1713655678.548571 received:Query executed successfully, but no result set was returned. ``` This bug requires injecting pocs from node1 to node3 at the same time as node4's poc is executing, and if a lock timeout can be triggered, there is a high probability that the bug will be reproduced. Architecture Information: ''' [NDBD DEFAULT] NoOfReplicas =2 DataMemory = 512M IndexMemory = 64M [NDB_MGMD] NodeId=1 hostname =192.172.10.8 datadir =/var/lib/mysql-cluster [NDBD] NodeId =2 hostname =192.172.10.9 datadir =/usr/local/mysql-cluster/data NodeGroup=0 [NDBD] NodeId =3 hostname =192.172.10.10 datadir =/usr/local/mysql-cluster/data NodeGroup=1 [NDBD] NodeId =4 hostname =192.172.10.11 datadir =/usr/local/mysql-cluster/data NodeGroup=0 [NDBD] NodeId =5 hostname =192.172.10.12 datadir =/usr/local/mysql-cluster/data NodeGroup=1 [mysqld] NodeId =6 hostname =192.172.10.9 [mysqld] NodeId =7 hostname =192.172.10.10 [mysqld] NodeId =8 hostname =192.172.10.11 [mysqld] NodeId =9 hostname =192.172.10.12 ''' How to repeat: 导入我提供的data文件，然后按一定次序执行poc，就可以复现。 Suggested fix: It looks like there is a problem with the scanning part of update, possibly related to the temp table.