A number of limitations exist in MySQL Cluster with regard to the handling of transactions. These include the following:
Transaction isolation level.
NDBCLUSTER storage engine
supports only the
COMMITTED transaction isolation level.
InnoDB, for example, supports
REPEATABLE READ, and
Section 18.104.22.168, “MySQL Cluster Backup Troubleshooting”,
for information on how this can affect backing up and
restoring Cluster databases.)
Transactions and BLOB or TEXT columns.
NDBCLUSTER stores only part
of a column value that uses any of MySQL's
TEXT data types in the
table visible to MySQL; the remainder of the
TEXT is stored in a
separate internal table that is not accessible to MySQL.
This gives rise to two related issues of which you should
be aware whenever executing
SELECT statements on tables
that contain columns of these types:
SELECT from a
MySQL Cluster table: If the
SELECT includes a
TEXT column, the
transaction isolation level is converted to a read with
read lock. This is done to guarantee consistency.
SELECT which uses
a primary key lookup or unique key lookup to retrieve
any columns that use any of the
TEXT data types and that
is executed within a transaction, a shared read lock is
held on the table for the duration of the
transaction—that is, until the transaction is
either committed or aborted. This does not occur for
queries that use index or table scans.
For example, consider the table
defined by the following
CREATE TABLE t ( a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, b INT NOT NULL, c INT NOT NULL, d TEXT, INDEX i(b), UNIQUE KEY u(c) ) ENGINE = NDB,
Either of the following queries on
causes a shared read lock, because the first query uses
a primary key lookup and the second uses a unique key
SELECT * FROM t WHERE a = 1; SELECT * FROM t WHERE c = 1;
However, none of the four queries shown here causes a shared read lock:
SELECT * FROM t WHERE b = 1; SELECT * FROM t WHERE d = '1'; SELECT * FROM t; SELECT b,c WHERE a = 1;
This is because, of these four queries, the first uses
an index scan, the second and third use table scans, and
the fourth, while using a primary key lookup, does not
retrieve the value of any
You can help minimize issues with shared read locks by
avoiding queries that use primary key lookups or unique
key lookups to retrieve
TEXT columns, or, in
cases where such queries are not avoidable, by
committing transactions as soon as possible afterward.
This limitation is lifted in MySQL Cluster NDB 7.0 (Bug #49190).
There are no partial transactions, and no partial
rollbacks of transactions. A duplicate key or similar
error aborts the entire transaction, and subsequent
statements raise ERROR 1296 (HY000): Got error
4350 'Transaction already aborted' from
NDBCLUSTER. In such cases, you must issue an
and retry the entire transaction.
This behavior differs from that of other transactional
storage engines such as
InnoDB that may
roll back individual statements.
Transactions and memory usage. As noted elsewhere in this chapter, MySQL Cluster does not handle large transactions well; it is better to perform a number of small transactions with a few operations each than to attempt a single large transaction containing a great many operations. Among other considerations, large transactions require very large amounts of memory. Because of this, the transactional behavior of a number of MySQL statements is effected as described in the following list:
DELETE FROM (even with no
WHERE clause) is
transactional. For tables containing a great many rows,
you may find that performance is improved by using
DELETE FROM ... LIMIT ...
statements to “chunk” the delete operation.
If your objective is to empty the table, then you may
wish to use
When executing a
INFILE statement, the
NDB engine performs
commits at irregular intervals that enable better
utilization of the communication network. It is not
possible to know ahead of time when such commits take
LOAD DATA FROM MASTER is not
supported in MySQL Cluster.