MySQL Bugs: #44286: Ndbd crashes after update query

Bug #44286	Ndbd crashes after update query
Submitted:	15 Apr 2009 10:38	Modified:	20 Jan 2016 10:38
Reporter:	Laurent Bigonville	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:	mysql-5.1-telco-6.3	OS:	Linux (Centos 5.3)
Assigned to:	MySQL Verification Team	CPU Architecture:	Any
Tags:	crash, mysql-5.1-telco-6.3.20

Description:
After updating a tables with about 1Million rows

Booth ndb nodes crashes at the same time.

On the client side I get:

Got temporary error 270 'Transaction aborted due to node shutdown' from
NDBCLUSTER
Got temporary error 4028 'Node failure caused abort of transaction' from
NDBCLUSTER
Got error 157 'Unknown error code' from NDBCLUSTER

How to repeat:
Database: dev_db;
mysql> update channel_2004 set kind=1;  
Query OK, 1071360 rows affected (1 min 3.54 sec)
Rows matched: 1071360  Changed: 1071360  Warnings: 0

ndb logs

Attachment: ndb_error_report_20090415103852.tar.bz2 (application/x-bzip, text), 426.22 KiB.

Easy workaround is to batch the updates using "where" clause on a PK.

Shows to be due to a GCP Stop.

Need to know about schema, was it using disk data

Might be duplicate of:
http://bugs.mysql.com/bug.php?id=37227
http://bugs.mysql.com/bug.php?id=39498
http://bugs.mysql.com/bug.php?id=43882

mysql> describe channel_2004;
+-------------+------------------+------+-----+-------------------+-----------------------------+
| Field       | Type             | Null | Key | Default           | Extra                       |
+-------------+------------------+------+-----+-------------------+-----------------------------+
| TS          | int(11) unsigned | NO   | PRI | 0                 |                             | 
| Frame       | int(6) unsigned  | NO   | PRI | 0                 |                             | 
| Interval    | int(6) unsigned  | NO   |     | 0                 |                             | 
| Modemid     | int(11) unsigned | NO   | MUL | 0                 |                             | 
| FirstFrame  | int(6) unsigned  | NO   |     | 0                 |                             | 
| Timeslot    | int(4) unsigned  | NO   |     | 0                 |                             | 
| Kind        | int(1) unsigned  | NO   | MUL | 0                 |                             | 
| Msgtype     | int(1) unsigned  | NO   |     | 0                 |                             | 
| Msn         | int(2) unsigned  | NO   |     | 0                 |                             | 
| Deleted     | int(1) unsigned  | NO   |     | 0                 |                             | 
| Lastupdated | timestamp        | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | 
+-------------+------------------+------+-----+-------------------+-----------------------------+

The table was in memory not in disk tablespace

Hi,

This is a GCP STOP issue. In modern MySQL Cluster we reduced the GCP STOP significantly but in some cases it is inevitable. 

You can read here: https://blogs.oracle.com/LinuxJedi/entry/mysql_cluster_gcp_stop about GCP STOP, how to avoid it, why it happens etc, it is not a bug, it is how MySQL Cluster behaves. 

Additionally to the blog post I linked, the 7.4 implements some queuing so that, in most cases, if you do more changes then your IO can handle it does not crash but queues the changes, still if you do too many changes compared to your IO capacity GCP STOP will inevitably happen.

Kind regards
Bogdan Kecman