Bug #114879 variable error in MySQL NDB cluster
Submitted: 4 May 12:12 Modified: 7 May 12:14
Reporter: CunDi Fang Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:8.0.35-cluster MySQL Cluster Community S OS:Any
Assigned to: MySQL Verification Team CPU Architecture:Any

[4 May 12:12] CunDi Fang
Description:
Hello, I found a bug in 8.0.35-cluster version of MYSQL cluster. This is by far the most variable bug I've encountered, he's shown at least 4 different states when I've tried to reproduce it.

This bug needs at least 2 nodes to repeat.

Node 1 Poc:
```
update mytest90.test1 set
  column1 = mytest90.test1.column4,
  column2 = mytest90.test1.column2,
  column5 = case when true then mytest90.test1.column5 else mytest90.test1.column5 end
    ,
  column6 = mytest90.test1.column6;
```

Node 2 Poc:
```
ALTER TABLE mytest90.test1 DROP COLUMN column3;
```

The requirement is that node1 then executes the update statement while node2's alter statement is executing. He showed the following four states when I tried to reproduce it:

result 1:
```
The update statement reports an error:
Got error 4009 'Cluster Failure' from NDBCLUSTER

node 1:1713501452.043485 , 1713501452.044517
node 2:1713501451.821443 , 1713501452.186541
```

result 2:
```
The update statement reports an error:
Table 'mytest90.test1' doesn't exist

node 1:start time: 1714823323.300178 end time:1714823323.301556
node 2:start time: 1714823323.000108 end time:1714823323.509685
```

result 3:
```
The alter statement reports an error:
Detected change to data in source table during copying ALTER TABLE. Alter aborted to avoid inconsistency.

node 1:start time: 1714823174.100162 end time:1714823174.125460
node 2:start time: 1714823174.000091 end time:1714823174.215103
```

result 4:
```
Both SQL executed successfully.

node 1:start time: 1714823648.300132 end time:1714823648.595222
node 2:start time: 1714823648.000099 end time:1714823648.528708
```

How to repeat:
Importing the database file I give later, and then executing Poc. Note that this bug is very demanding on the execution time of the statement.

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
'''

Suggested fix:
There should be a conflict between the update statement and the alter statement.
[7 May 8:27] MySQL Verification Team
Hi,

I cannot reproduce this and log file do not contain data about this errors you say you experienced.
[7 May 12:14] CunDi Fang
I apologize for this, but I did follow your steps of "shutdown cluster, delete log file, restart cluster, reproduce" and got the log file zip file by commanding "ndb_error_reporter /var/lib/mysqluster/ config.ini root", I don't know why this error is not recorded in the log file, maybe because some log-related configuration is not enabled? This bug can be reproduced by typing the sql statement directly on the node, and as long as the timing of the sql statement is controlled, it can be reproduced with a high probability.