16.9. Known Limitations of MySQL Cluster
In this section, we provide a list of known limitations in MySQL
Cluster releases in the 5.1.x series compared to
features available when using the
InnoDB storage engines. Currently, there are no
plans to address these in coming releases of MySQL
5.1; however, we will attempt to supply fixes for
these issues in subsequent release series. If you check the
“Cluster” category in the MySQL bugs database at
http://bugs.mysql.com, you can find known bugs
which (if marked “5.1”) we intend to
correct in upcoming releases of MySQL 5.1.
The list here is intended to be complete with respect to the
conditions just set forth. You can report any discrepancies that
you encounter to the MySQL bugs database using the instructions
given in Section 1.8, “How to Report Bugs or Problems”. If we do not plan to fix
the problem in MySQL 5.1, we will add it to the list.
Noncompliance in syntax
(resulting in errors when running existing applications):
Text indexes are not supported.
BIT column cannot be a primary key or
part of a composite primary key.
Geometry datatypes (
WKB) are supported in
NDB tables in MySQL 5.1.
However, spatial indexes are not supported.
It is not possible to drop partitions from
NDB tables using
... DROP PARTITION. The other partitioning
ALTER TABLE —
PARTITION — are supported for Cluster
tables, but use copying and so are not optimised. See
Section 17.3.1, “Management of
LIST Partitions” and
Section 13.1.2, “
ALTER TABLE Syntax”.
As of MySQL 5.1.6, all Cluster tables are by default
KEY using the table's
primary key as the partitioning key. If no primary key is
explicitly set for the table, the “hidden”
primary key automatically created by the
NDB storage engine is used instead. For
additional discussion of these and related issues, see
Section 17.2.4, “
Non-compliance in limits or
behavior (may result in errors when running
NDB Cluster supports only the
READ COMMITTED transaction
There is no partial rollback of transactions. A
duplicate key or similar error results in a rollback
of the entire transaction.
Important: If a
SELECT from a Cluster table
transaction isolation level is converted to a read
with read lock. This is done to guarantee consistency,
due to the fact that parts of the values stored in
columns of these types are actually read from a
A number of hard limits exist which are configurable, but
available main memory in the cluster sets limits. See the
complete list of configuration parameters in
Section 16.4.4, “Configuration File”. Most
configuration parameters can be upgraded online. These
hard limits include:
Database memory size and index memory size
The maximum number of transactions that can be
performed is set using the configuration parameter
that bulk loading,
ALTER TABLE are handled as
special cases by running multiple transactions, and so
are not subject to this limitation.
Different limits related to tables and indexes. For
example, the maximum number of ordered indexes per
table is determined by
Database names, table names and attribute names cannot be
as long in
NDB tables as with other
table handlers. Attribute names are truncated to 31
characters, and if not unique after truncation give rise
to errors. Database names and table names can total a
maximum of 122 characters. (That is, the maximum length
NDB Cluster table name is 122
characters less the number of characters in the name of
the database of which that table is a part.)
All Cluster table rows are of fixed length. This means
(for example) that if a table has one or more
VARCHAR fields containing only
relatively small values, more memory and disk space is
required when using the
engine than would be the case for the same table and data
MyISAM engine. (In other
words, in the case of a
the column requires the same amount of storage as a
CHAR column of the same size.)
The maximum number of tables in a Cluster database is
limited to 1792.
The maximum number of attributes per table is limited to
The maximum permitted size of any one row is 8KB,
not including data stored in
The maximum number of attributes per key is 32.
Unsupported features (do not
cause errors, but are not supported or enforced):
The foreign key construct is ignored, just as it is in
Savepoints and rollbacks to savepoints are ignored as in
Performance and limitation-related
There are query performance issues due to sequential
access to the
NDB storage engine; it is
also relatively more expensive to do many range scans than
it is with either
Records in range statistic is not
supported, resulting in non-optimal query plans in some
USE INDEX or
FORCE INDEX as a workaround.
Unique hash indexes created with
HASH cannot be used for accessing a table if
NULL is given as part of the key.
MySQL Cluster does not support durable commits on disk.
Commits are replicated, but there is no guarantee that
logs are flushed to disk on commit.
The only supported isolation level is
COMMITTED. (InnoDB supports
REPEATABLE READ, and
Section 184.108.40.206, “Backup Troubleshooting”,
for information on how this can effect backup and restore
of Cluster databases.
No durable commits on disk. Commits are replicated, but
there is no guarantee that logs are flushed to disk on
Problems relating to multiple MySQL
servers (not relating to
ALTER TABLE is not fully locking when
running multiple MySQL servers (no distributed table
MySQL replication will not work correctly if updates are
done on multiple MySQL servers. However, if the database
partitioning scheme is done at the application level and
no transactions take place across these partitions,
replication can be made to work.
Autodiscovery of databases is not supported for multiple
MySQL servers accessing the same MySQL Cluster. However,
autodiscovery of tables is supported in such cases. What
this means is that after a database named
db_name is created or imported
using one MySQL server, you should issue a
statement on each additional MySQL server that accesses
the same MySQL Cluster. Once this has been done for a
given MySQL server, that server should be able to detect
the database tables without error.
Issues exclusive to MySQL
Cluster (not related to
All machines used in the cluster must have the same
architecture. That is, all machines hosting nodes must be
either big-endian or little-endian, and you cannot use a
mixture of both. For example, you cannot have a management
node running on a PowerPC which directs a data node that
is running on an x86 machine. This restriction does not
apply to machines simply running mysql
or other clients that may be accessing the cluster's SQL
It is not possible to make online schema changes such as
those accomplished using
ALTER TABLE or
CREATE INDEX, as the
Cluster does not support autodiscovery of such
changes. (However, you can import or create a table that
uses a different storage engine, and then convert it to
. In such a case, you must
FLUSH TABLES statement to force
the cluster to pick up the change.)
Online adding or dropping of nodes is not possible (the
cluster must be restarted in such cases).
When using multiple management servers:
You must give nodes explicit IDs in connectstrings
because automatic allocation of node IDs does not work
across multiple management servers.
You must take extreme care to have the same
configurations for all management servers. No special
checks for this are performed by the cluster.
In order that management nodes be able to see one
another, you must restart all data nodes after
bringing up the cluster. (See Bug #13070 for a
Multiple network interfaces for data nodes are not
supported. Use of these is liable to cause problems: In
the event of a data node failure, an SQL node waits for
confirmation that the data node went down but never
receives it because another route to that data node
remains open. This can effectively make the cluster
The maximum number of data nodes is 48.
The total maximum number of nodes in a MySQL Cluster is
63. This number includes all MySQL Servers (SQL nodes),
data nodes, and management servers.
The maximum number of metadata objects in MySQL 5.1
Cluster is 20320. This limit is hard-coded.