MySQL Cluster Tutorial - cdn.oreillystatic.com

Fault tolerance
MySQL Cluster is designed to be very fault tolerant. Although there are issues you should
be aware of. This section will cover how cluster is fault tolerant and how your application
should work with this.
MySQL Server
When using MySQL in general temporary errors can happen, that is to say errors that may
not occur if the transaction is retried. In MySQL Cluster this can happen more often than
other storage engines for a variety of reasons, such as timeouts, node failures or redo log
problems. With MySQL Cluster when this happens the transaction will be implicitly
rolled-back and the error will be returned to the client. It is up to the client application to
retry the transaction.
Sometimes the error message returned will not give enough details to find the true cause of
the failure, so it is a good idea to run 'SHOW WARNINGS' after an error to see other messages
from cluster. For example, if there is a transaction exclusive locking some rows this could
happen:
mysql> select * from t1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
This is kind of useful, but MySQL Cluster has 5 different things that can cause this error.
So:
mysql> show warnings\G
*************************** 1. row ***************************
Level: Error
Code: 1297
Message: Got temporary error 274 'Time-out in NDB, probably caused by deadlock'
from NDB
*************************** 2. row ***************************
Level: Error
Code: 1297
Message: Got temporary error 274 'Time-out in NDB, probably caused by deadlock'
from NDB
*************************** 3. row ***************************
Level: Error
Code: 1205
Message: Lock wait timeout exceeded; try restarting transaction
*************************** 4. row ***************************
Level: Error
Code: 1622
Message: Storage engine NDB does not support rollback for this statement.
Transaction rolled back and must be restarted
4 rows in set (0.00 sec)
So, the error here is NDB error code 274, it is now possible for the MySQL cluster team to
find out the cause of this (274 is triggered by TransactionDeadLockDetectionTimeOut
exceeded during a scan operation).
Heartbeats
The data nodes use a system of heartbeats in a ring to make sure that a node's neighbour is
still up and running. The heartbeat interval is set using the HeartbeatIntervalDBDB setting
which is 1500ms by default. A cluster node will be declared dead if it is not heard from
Copyright © 2010, Oracle and/or its affiliates. All rights reserved. 34/81