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 10.5, “Data Type Storage Requirements”).
For MySQL Cluster Disk Data tables, the fixed-width limitation continues to apply. See Section 17.5.10, “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 Cluster
replication beginning with MySQL 5.1.20, MySQL Cluster NDB
6.2.5, and MySQL Cluster 6.3.2.
Database autodiscovery and online schema changes.
Autodiscovery of databases is now supported for multiple
MySQL servers accessing the same MySQL Cluster. Formerly,
autodiscovery in MySQL Cluster 5.1 and MySQL Cluster NDB
6.x releases required that a given
mysqld was already running and
connected to the cluster at the time that the database was
created on a different mysqld —
in other words, when a mysqld process
connected to the cluster after a database named
db_name
was created, it was
necessary to issue a CREATE DATABASE
or
db_name
CREATE SCHEMA
statement on
the “new” MySQL server when it first
accesseed that MySQL Cluster. Beginning with MySQL Cluster
NDB 6.2.16 and MySQL Cluster NDB 6.3.18, such a
db_name
CREATE
statement is no longer required.
(Bug#39612)
This also means that online schema changes in
NDB
tables are now possible.
That is, the result of operations such as
ALTER TABLE
and
CREATE INDEX
performed on one
SQL node in the cluster are now visible to the cluster's
other SQL nodes without any additional action being taken.
Backup and restore between architectures. Beginning with MySQL 5.1.10, 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)
Character set directory.
Beginning with MySQL 5.1.10, it is possible to install
MySQL with Cluster support to a nondefault location and
change the search path for font description files using
either the --basedir
or
--character-sets-dir
options. (Previously, ndbd in MySQL 5.1
searched only the default path — typically
/usr/local/mysql/share/mysql/charsets
— for character sets.)
Multiple management servers. In MySQL 5.1 (including all MySQL Cluster NDB 6.x versions), it is no longer necessary, when running multiple management servers, to restart all the cluster's data nodes to enable the management nodes to see one another.
Also, when using multiple management servers and starting concurrently several API nodes (possibly including one or more SQL nodes) whose connectstrings listed the management servers in different order, it was possible for 2 API nodes to be assigned the same node ID. This issue is resolved in MySQL Cluster NDB 6.2.17, 6.3.23, and 6.4.3. (Bug#42973)
Multiple data node processes per host. Beginning with MySQL Cluster NDB 6.2.0, you can use multiple data node processes on a single host. (In MySQL Cluster NDB 6.1, MySQL 5.1, and earlier release series, we did not support production MySQL Cluster deployments in which more than one ndbd process was run on a single physical machine.)
In addition, MySQL Cluster NDB 7.0 introduces support for multi-threaded data nodes (ndbmtd). See Section 17.1.4.5, “MySQL Cluster Development in MySQL Cluster NDB 7.0”, and 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. Prior to MySQL Cluster NDB 6.1.1, the total maximum number of nodes in a MySQL Cluster was 63, including all SQL nodes (MySQL Servers), API nodes (applications accessing the cluster other than MySQL servers), data nodes, and management servers.
Starting with MySQL Cluster NDB 6.1.1, 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 beginning with this version is 63, of which up to 48 can be data nodes.
The limitation that a data node cannot have a node ID greater than 49 continues to apply.
Recovery of memory from deleted rows.
Beginning with MySQL Cluster NDB 6.3.7, 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
still 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 12.1.17, “CREATE TABLE
Syntax”, and
Section 12.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).
Implicit Rollbacks.
Prior to MySQL Cluster NDB 6.2.17 and MySQL Cluster NDB
6.3.19, MySQL Cluster did not automtically roll back a
transaction that was aborted by a duplicate key or similar
error, and subsequent statements raised ERROR
1296 (HY000): Got error 4350 'Transaction already aborted'
from NDBCLUSTER. In such cases, it was
necessary to issue an explicit
ROLLBACK
statement first, and then to retry the entire transaction.
Beginning with MySQL Cluster NDB 6.2.17 and MySQL Cluster NDB 6.3.19, this limitation has been removed; now, an error which causes a transaction to be aborted generates an implicit rollback of the entire transaction. This is logged with the warning Storage engine NDB does not support rollback for this statement. Transaction rolled back and must be restarted. A statement subsequent to this starts a new transaction. (Bug#32656)
The NDBCLUSTER
storage engine
does not support partial transactions or partial rollbacks
of transactions in any version of MySQL Cluster.
Number of tables.
Previously, the maximum number of
NDBCLUSTER
tables in a single
MySQL Cluster was 1792, but this is no longer the case in
MySQL 5.1 and later MySQL Cluster releases. However, the
number of tables is still included in the total maximum
number of NDBCLUSTER
database
objects (20320). (See
Section 17.1.5.5, “Limits Associated with Database Objects in MySQL Cluster”.)
DDL operations.
Beginning with MySQL Cluster NDB 6.4.0, DDL operations
(such as CREATE TABLE
or
ALTER TABLE
) are protected
from data node failures. Previously, if a data node failed
while trying to perform one of these, the data dictionary
became locked and no further DDL statements could be
executed without restarting the cluster (Bug#36718).
Adding and dropping of data nodes. In MySQL Cluster NDB 6.3 and previous versions of MySQL Cluster, the online adding or dropping of data nodes was not possible; such operations required a complete shutdown and restart of the entire cluster. In MySQL Cluster NDB 7.0 (beginning with MySQL Cluster NDB 6.4.0) and later MySQL Cluster release series, 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 in MySQL Cluster NDB 7.0 or MySQL Cluster NDB 7.1, 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 yet be dropped online. Reducing the number of data nodes still 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.11, “Adding MySQL Cluster Data Nodes Online”.
Native support for default column values.
Starting with MySQL Cluster 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 MySQL Cluster releases can
still be used in MySQL Cluster 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
ALTER TABLE
statement.
You cannot set or change a table column's default
value using an online ALTER
TABLE
operation
User Comments
Add your own comment.