A number of limitations and related issues existing in earlier versions of NDB Cluster have been resolved:
Variable-length column support. The
NDBCLUSTERstorage engine now supports variable-length column types for in-memory tables.
Previously, for example, any Cluster table having one or more
VARCHARfields which contained only relatively small values, much more memory and disk space were required when using the
NDBCLUSTERstorage engine than would have been the case for the same table and data using the
MyISAMengine. In other words, in the case of a
VARCHARcolumn, such a column required the same amount of storage as a
CHARcolumn 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
BINARYare comparable to those for these column types when used in
MyISAMtables (see Data Type Storage Requirements).Important
For NDB Cluster Disk Data tables, the fixed-width limitation continues to apply. See Section 7.12, “NDB Cluster Disk Data Tables”.
Replication with NDB Cluster. It is now possible to use MySQL replication with Cluster databases. For details, see Chapter 8, NDB Cluster Replication.
Circular Replication. Circular replication is also supported with NDB Cluster, beginning with MySQL 5.1.18. See Section 8.10, “NDB Cluster Replication: Multi-Master and Circular 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, multithreaded data nodes. NDB Cluster 7.2 supports multiple data node processes on a single host as well as multithreaded data node processes. See Section 6.3, “ndbmtd — The NDB 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
NDBtables as tables using other storage engines, because attribute names were truncated internally. In MySQL 5.1 and later, names of NDB 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 TABLEstatements 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,
UPDATE IGNORE, and
REPLACEwere 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.
AUTO_INCREMENT columns. In MySQL 5.1.10 and earlier versions, the maximum number of tables having
AUTO_INCREMENTcolumns—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 an NDB 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.Note
A data node cannot have a node ID greater than 49.
Only in-memory tables are supported; the
OPTIMIZE TABLEstatement has no effect on NDB Cluster Disk Data tables.
You can regulate the effects of
OPTIMIZEon 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
NDBCLUSTERtables in a single NDB Cluster is included in the total maximum number of
NDBCLUSTERdatabase objects (20320). (See Section 3.7.5, “Limits Associated with Database Objects in NDB Cluster”.)
Adding and dropping of data nodes. In NDB Cluster 7.2 (NDB Cluster 7.0 and later), it is possible to add new data nodes to a running NDB 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 an NDB 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 NDB Cluster releases, it is not possible to change online either the number of replicas (
NoOfReplicasconfiguration 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 7.14, “Adding NDB Cluster Data Nodes Online”.
Native support for default column values. Starting with NDB 7.1.0, default values for table columns are stored by
NDBCLUSTER, rather than by the MySQL server as was previously the case. Because less data must be sent from an SQL node to the data nodes, inserts on tables having column value defaults can be performed more efficiently than before.
Tables created using previous NDB Cluster releases can still be used in NDB 7.1.0 and later, although they do not support native default values and continue to use defaults supplied by the MySQL server until they are upgraded. This can be done by means of an offline
You cannot set or change a table column's default value using an 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
MyISAMstorage engine. Beginning with NDB 7.2.0, it is possible, following installation of the NDB Cluster software and setup of the desired users and privileges on one SQL node, to convert the grant tables to use
NDBand 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 NDB Cluster distribution. For more information, see Section 7.15, “Distributed MySQL Privileges for NDB Cluster”.
Number of rows per partition. Previously, a single NDB Cluster partition could hold a maximum of 46137488 rows. This limitation was removed in NDB 7.2.9. (Bug #13844405, Bug #14000373)
If you are still using a previous NDB 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 3.2, “NDB 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.
NDB Cluster 7.2 also supports increasing the number of data nodes in the cluster while the cluster remains in operation. See Section 7.14, “Adding NDB Cluster Data Nodes Online”, for more information.