A number of limitations and related issues existing in earlier versions of MySQL Cluster have been resolved:
Variable-length column support.
The NDBCLUSTER storage engine
now supports variable-length column types for in-memory
tables.
Previously, for example, any Cluster table having one or
more VARCHAR fields which
contained only relatively small values, much more memory and
disk space were required when using the
NDBCLUSTER storage engine than
would have been the case for the same table and data using
the MyISAM engine. In other words, in the
case of a VARCHAR column,
such a column required the same amount of storage as a
CHAR column of the same size.
In MySQL 5.1, this is no longer the case for in-memory
tables, where storage requirements for variable-length
column types such as VARCHAR
and BINARY are comparable to those for
these column types when used in MyISAM
tables (see Section 11.6, “Data Type Storage Requirements”).
For MySQL Cluster Disk Data tables, the fixed-width limitation continues to apply. See Section 17.5.12, “MySQL Cluster Disk Data Tables”.
Replication with MySQL Cluster. It is now possible to use MySQL replication with Cluster databases. For details, see Section 17.6, “MySQL Cluster Replication”.
Circular Replication. Circular replication is also supported with MySQL Cluster, beginning with MySQL 5.1.18. See Section 17.6.10, “MySQL Cluster Replication: Multi-Master and Circular Replication”.
auto_increment_increment and
auto_increment_offset.
The
auto_increment_increment
and auto_increment_offset
server system variables are supported for MySQL Cluster
Replication.
Backup and restore between architectures. It is possible to perform a Cluster backup and restore between different architectures. Previously—for example—you could not back up a cluster running on a big-endian platform and then restore from that backup to a cluster running on a little-endian system. (Bug #19255)
Multiple data nodes, multi-threaded data nodes. MySQL Cluster NDB 7.2 supports multiple data node processes on a single host as well as multi-threaded data node processes. See Section 17.4.3, “ndbmtd — The MySQL Cluster Data Node Daemon (Multi-Threaded)”, for more information.
Identifiers.
Formerly (in MySQL 5.0 and earlier), database names, table
names and attribute names could not be as long for
NDB tables as tables using
other storage engines, because attribute names were
truncated internally. In MySQL 5.1 and later, names of
MySQL Cluster databases, tables, and table columns follow
the same rules regarding length as they do for any other
storage engine.
Length of CREATE TABLE statements.
CREATE TABLE statements may
be no more than 4096 characters in length. This
limitation affects MySQL 5.1.6, 5.1.7, and 5.1.8
only. (See Bug #17813)
IGNORE and REPLACE
functionality.
In MySQL 5.1.7 and earlier,
INSERT
IGNORE,
UPDATE
IGNORE, and
REPLACE were supported only
for primary keys, but not for unique keys. It was possible
to work around this issue by removing the constraint, then
dropping the unique index, performing any inserts, and
then adding the unique index again.
This limitation was removed for
INSERT
IGNORE and REPLACE
in MySQL 5.1.8. (See Bug #17431.)
AUTO_INCREMENT columns.
In MySQL 5.1.10 and earlier versions, the maximum number
of tables having AUTO_INCREMENT
columns—including those belonging to hidden primary
keys—was 2048.
This limitation was lifted in MySQL 5.1.11.
Maximum number of cluster nodes. The total maximum number of nodes in a MySQL Cluster is 255, including all SQL nodes (MySQL Servers), API nodes (applications accessing the cluster other than MySQL servers), data nodes, and management servers. The total number of data nodes and management nodes is 63, of which up to 48 can be data nodes.
A data node cannot have a node ID greater than 49.
Recovery of memory from deleted rows.
Memory can be reclaimed from an
NDB table for reuse with any
NDB table by employing
OPTIMIZE TABLE, subject to
the following limitations:
Only in-memory tables are supported; the
OPTIMIZE TABLE statement
has no effect on MySQL Cluster Disk Data tables.
Only variable-length columns (such as those declared as
VARCHAR,
TEXT, or
BLOB) are supported.
However, you can force columns defined using
fixed-length data types (such as
CHAR) to be dynamic using
the ROW_FORMAT or
COLUMN_FORMAT option with a
CREATE TABLE or
ALTER TABLE statement.
See Section 13.1.17, “CREATE TABLE Syntax”, and
Section 13.1.7, “ALTER TABLE Syntax”, for information on these
options.
You can regulate the effects of OPTIMIZE
on performance by adjusting the value of the global system
variable ndb_optimization_delay, which
sets the number of milliseconds to wait between batches of
rows being processed by OPTIMIZE. The
default value is 10 milliseconds. It is possible to set a
lower value (to a minimum of 0), but not
recommended. The maximum is 100000 milliseconds (that is,
100 seconds).
Number of tables.
The maximum number of
NDBCLUSTER tables in a single
MySQL Cluster is included in the total maximum number of
NDBCLUSTER database objects
(20320). (See
Section 17.1.6.5, “Limits Associated with Database Objects in MySQL Cluster”.)
Adding and dropping of data nodes. In MySQL Cluster NDB 7.2 (MySQL Cluster NDB 7.0 and later), it is possible to add new data nodes to a running MySQL Cluster by performing a rolling restart, so that the cluster and the data stored in it remain available to applications.
When planning to increase the number of data nodes in the cluster online, you should be aware of and take into account the following issues:
New data nodes can be added online to a MySQL Cluster only as part of a new node group.
New data nodes can be added online, but cannot be dropped online. Reducing the number of data nodes requires a system restart of the cluster.
As in previous MySQL Cluster releases, it is not
possible to change online either the number of replicas
(NoOfReplicas
configuration parameter) or the number of data nodes per
node group. These changes require a system restart.
Redistribution of existing cluster data using the new data nodes is not automatic; however, this can be accomplished using simple SQL statements in the mysql client or other MySQL client application once the nodes have been added. During this procedure, it is not possible to perform DDL operations, although DML operations can continue as normal.
The distribution of new cluster data (that is, data stored in the cluster after the new nodes have been added) uses the new nodes without manual intervention.
For more information, see Section 17.5.13, “Adding MySQL Cluster Data Nodes Online”.
Distribution of MySQL users and privileges.
Previously, MySQL users and privileges created on one SQL
node were unique to that SQL node, due to the fact that
the MySQL grant tables were restricted to using the
MyISAM storage engine.
Beginning with MySQL Cluster NDB 7.2.0, it is possible,
following installation of the MySQL Cluster software and
setup of the desired users and privileges on one SQL node,
to convert the grant tables to use
NDB and thus to distribute
the users and privileges across all SQL nodes connected to
the cluster. You can do this by loading and making use of
a set of stored procedures defined in an SQL script
supplied with the MySQL Cluster distribution. For more
information, see
Section 17.5.14, “Distributed MySQL Privileges for MySQL Cluster”.
Number of rows per partition. Previously, a single MySQL Cluster partition could hold a maximum of 46137488 rows. This limitation was removed in MySQL Cluster NDB 7.2.9. (Bug #13844405, Bug #14000373)
If you are still using a previous MySQL Cluster release, you can work around this limitation by taking advantage of the fact that the number of partitions is the same as the number of data nodes in the cluster (see Section 17.1.2, “MySQL Cluster Nodes, Node Groups, Replicas, and Partitions”). This means that, by increasing the number of data nodes, you can increase the available space for storing data.
MySQL Cluster NDB 7.2 also supports increasing the number of data nodes in the cluster while the cluster remains in operation. See Section 17.5.13, “Adding MySQL Cluster Data Nodes Online”, for more information.
It is also possible to increase the number of partitions for
NDB tables by using explicit
KEY or LINEAR KEY
partitioning (see Section 18.2.5, “KEY Partitioning”).

User Comments
Add your own comment.