The following list provides an overview of significant feature additions and changes made in MySQL Cluster NDB 7.0. For more detailed information about all feature changes and bugfixes made in MySQL Cluster NDB 7.0, see Section 17.7.2, “Changes in MySQL Cluster NDB 7.0”.
Early development versions of MySQL Cluster NDB 7.0 were known as “MySQL Cluster NDB 6.4”, and the first four releases in this series were identified as MySQL Cluster NDB 6.4.0 through 6.4.3. Any information relating to these MySQL Cluster NDB 6.4.x releases appearing in this documentation apply to MySQL Cluster NDB 7.0.
MySQL Cluster NDB 7.0.4 is the fifth MySQL Cluster NDB 7.0 release; it is the successor to MySQL Cluster NDB 6.4.3.
MySQL Cluster on Windows (alpha).
MySQL Cluster is now available on an experimental basis
for Windows operating systems. Features and behavior
comparable to those found on platforms that are already
supported — such as Linux and Solaris — are
planned for MySQL Cluster on Windows. Currently, you must
build from source, although we intend to start making
Windows binaries available in the near future. To enable
MySQL Cluster support on Windows, you must configure the
build using the
For more information, see
Section 2.5.10, “Installing MySQL from Source on Windows”.
Ability to add nodes and node groups online.
Beginning with MySQL Cluster NDB 6.4.0, it is possible to
add new node groups (and thus new data nodes) to a running
MySQL Cluster without shutting down and reloading the
cluster. As part of enabling this feature, a new command
CREATE NODEGROUP has been added to the
cluster management client and the functionality of the
TABLE ... REORGANIZE PARTITION SQL statement has
been extended. For more information, see
Section 17.5.11, “Adding MySQL Cluster Data Nodes Online”.
Data node multithreading support.
Beginning with MySQL Cluster NDB 6.4.0, a multithreaded
version of the data node daemon, named
ndbmtd, is available for use on data
node hosts with multiple CPU cores. This binary is built
automatically when compiling with MySQL Cluster support;
no additional options other than those needed to provide
MySQL Cluster support are needed when configuring the
build. In most respects, ndbmtd
functions in the same way as ndbd, and
can use the same command-line options and configuration
parameters. In addition, the new
parameter can be used to determine the number of data node
process threads for ndbmtd. For more
Section 17.4.3, “ndbmtd — The MySQL Cluster Data Node Daemon (Multi-Threaded)”.
Disk Data tables are not yet supported for use with ndbmtd.
Formerly, MySQL Cluster configuration was stateless
— that is, configuration information was reloaded
from the cluster's global configuration file (usually
config.ini) each time
ndb_mgmd was started. Beginning with
MySQL Cluster NDB 6.4.0, the cluster's configuration
is cached internally, and the global configuration file is
no longer automatically re-read when the management server
is restarted. This behavior can be controlled via the
three new management server options
--reload. For more information about
this change, see
Section 17.3.2, “MySQL Cluster Configuration Files”. For more
information about the new management server options, see
Section 17.4.4, “ndb_mgmd — The MySQL Cluster Management Server Daemon”.
Snapshot options for backups.
Beginning with MySQL Cluster NDB 6.4.0, you can determine
when performing a cluster backup whether the backup
matches the state of the data when the backup was started
or when it was completed, using the new options
SNAPSHOTEND for the management
START BACKUP command. See
Section 126.96.36.199, “Using The MySQL Cluster Management Client to Create a Backup”,
for more information.
Dynamic NDB transporter send buffer memory allocation.
Previously, the NDB kernel used a fixed-size send buffer
for every data node in the cluster, which was allocated
when the node started. Because the size of this buffer
could not be changed after the cluster was started, it was
necessary to make it large enough in advance to accomodate
the maximum possible load on any transporter socket.
However, this was an inefficient use of memory, since much
of it often went unused. Beginning with MySQL Cluster NDB
6.4.0, send buffer memory is allocated dynamically from a
memory pool shared between all transporters, which means
that the size of the send buffer can be adjusted as
necessary. This change is reflected by the addition of the
OverLoadLimit, as well as a change in
how the existing
configuration parameter is used. For more information, see
Section 188.8.131.52, “Configuring MySQL Cluster Send Buffer Parameters”.
Robust DDL operations.
Beginning with MySQL Cluster NDB 6.4.0, DDL operations
CREATE TABLE or
ALTER TABLE) are protected
from data node failures; in the event of a data node
failure, such operations are now rolled back gracefully.
Previously, if a data node failed while trying to perform
a DDL operation, the MySQL Cluster data dictionary became
locked and no further DDL statements could be executed
without restarting the cluster.
IPv6 support in MySQL Cluster Replication. Beginning with MySQL Cluster NDB 6.4.1, IPv6 networking is supported between MySQL Cluster SQL nodes, which makes it possible to replicate between instances of MySQL Cluster using IPv6 addresses. However, IPv6 is supported only for direct connections between MySQL servers; all connections within an individual MySQL Cluster must use IPv4. For more information, see Section 17.6.3, “Known Issues in MySQL Cluster Replication”.
Restoring specific databases, tables, or columns from a MySQL Cluster
It is now possible to exercise more fine-grained control
when restoring a MySQL Cluster from backup using
ndb_restore. Beginning with MySQL
Cluster NDB 6.4.3, you can choose to restore only
specified tables or databases, or exclude specific tables
or databases from being restored, using the new
--exclude-databases. Beginning with MySQL
Cluster NDB 7.0.7, it is also possible to restore to a
table having fewer columns than the original using the
--exclude-missing-columns option. For
more information about all of these options, see
Section 17.4.17, “ndb_restore — Restore a MySQL Cluster Backup”.
Improved Disk Data filesystem configuration.
As of MySQL Cluster NDB 6.4.3, you can specify default
locations for MySQL Cluster Disk Data data files and undo
log files using the data node configuration parameters
eliminates the need to use symbolic links in order to
place Disk Data files separately from other files in data
node filesystems to improve Disk Data performance. For
more information, see
Disk Data filesystem parameters.
Automatic creation of Disk Data log file groups and tablespaces.
Beginning with MySQL Cluster NDB 6.4.3, using the data
node configuration parameters
InitialTablespace, you can cause the
creation of a MySQL Cluster Disk Data log file group,
tablespace, or both, when the cluster is first started.
When using these parameters, no SQL statements are
required to create these Disk Data objects. For more
Data object creation parameters.
Improved internal message passing and record handling. MySQL Cluster NDB 7.0 contains 2 changes that optimize the use of network connections by addressing the size and number of messages passed between data nodes, and between data nodes and API nodes, which can increase MySQL Cluster and application performance:
Packed reads. Formerly, each read request signal contained a list of columns to be retrieved, each of these column identifiers using 4 bytes within the message. This meant that the message size increased as the number of columns being fetched increased. In addition, in the response from the data node, each column result was packed to a 4-byte boundary, which resulted in wasted space. In MySQL Cluster NDB 7.0, messaging for read operations is optimized in both directions, using a bitmap in the read request to specify the columns to be fetched. Where many fields are requested, this can result in a significant message size reduction as compared with the old method. In addition, the 4-byte packing in responses is no longer used, which means that smaller fields consume less space.
Long signal transactions. This enhancement reduces the number of messages and signals that are sent to data nodes for complex requests. Prior to MySQL Cluster NDB 7.0, there was a 100 byte limit on the size of the request signal, which meant that complex requests had to be split up between multiple messages prior to transmission, then reassembled on the receiving end. In addition to actual payload data, each message required its own operating system and protocol overhead such as header information. This often wasted network bandwidth and data node CPU. The maximum size of the message is now 32 KB, which is sufficient to accommodate most queries.
Both of these optimizations are internal to the NDB API, and so is transparent to applications; this is true whether an application uses the NDB API directly or does so indirectly through an SQL node.
Configuration parameter data dumps.
Starting with MySQL Cluster NDB 7.0.6, the
ndb_config utility supports a
--configinfo option that causes it to
dump a list of all configuration parameters supported by
the cluster, along with brief descriptions, information
about the parameters' default and allowed values, and
the sections of the
in which the parameters apply. An additional
--xml switch causes
ndb_config to use XML rather than
plaintext output. Using ndb_config
--xml requires no access to a running
MySQL Cluster, any other programs, or any files. For more
information and examples, see
Section 17.4.6, “ndb_config — Extract MySQL Cluster Configuration Information”.
Per-table reporting of free space on disk.
table shows information about used and free space in MySQL
Cluster Disk Data data files, but this information is not
applicable to individual tables. In MySQL Cluster NDB
7.0.8 and later, the ndb_desc utility
provides two additional columns in its output that show
the amount of space allocated on disk for a given
NDB table as well the amount
of space that remains available for additional storage of
disk-based column data for that table. For more
Section 17.4.9, “ndb_desc — Describe NDB Tables”.
Improved restart times. Optimizations in redo log handling and other filesystem operations introduced in MySQL Cluster NDB 7.0.9 have the potential to reduce considerably the time required for restarts. While actual performance benefits observed in production setups will naturally vary depending on database size, hardware, and other conditions, our own preliminary testing has shown that these improvements can yield startup times that are faster than those typical of previous MySQL Cluster NDB 7.0 releases by a factor of 50 or more.
--nowait-nodes option for management
Starting with MySQL Cluster NDB 7.0.10, it is possible to
configure a cluster with two management servers, but to
start the cluster using only one of them by starting the
management node daemon with the
The other management server can then be started at a later
time to join the running MySQL Cluster.
Increased flexibility in online upgrade procedure. Previously, when performing an upgrade of a running MySQL cluster, the order in which the types of cluster nodes had to be upgraded was very strict. However, beginning with MySQL Cluster NDB 7.0.10, MySQL Cluster supports online upgrading of API nodes (including MySQL servers running as SQL nodes) online upgrading management nodes, data nodes, or both.
Before attempting to use this new upgrade functionality, see Section 184.108.40.206, “Performing a Rolling Restart of a MySQL Cluster”, for additional information, especially if you are planning an online upgrade to MySQL Cluster NDB 7.0 from MySQL Cluster NDB 6.3.
New replication conflict resolution strategy.
Beginning with MySQL Cluster NDB 7.0.11, the function
NDB$MAX_DELETE_WIN() is available to
implement “greatest timestamp, delete wins”
conflict resolution. See
for more information.
Improved lock handling for primary key lookups on
A MySQL Cluster table stores all but the first 256 bytes
TEXT column values in a
BLOB table; when
executing queries against such tables, a shared lock is
obtained. Prior to MySQL Cluster NDB 7.0.12, when the
query used a primary key lookup and took place within a
transaction, the lock was held for the duration of the
transaction, even after no more data was being read from
NDB table. Now in such
cases, the lock is released when all
BLOB data associated with
the table has been read. (Bug#49190)
A shared lock is also taken for unique key lookups; it is still the case that this lock is held for the duration of the transaction.
Heartbeat thread policy and priority.
Beginning with MySQL Cluster NDB 7.0.13, a new
HeartbeatThreadPriority makes it
possible to set the policy and the priority for the
heartbeat thread on management and API nodes.
Improved access to partitioning information.
The ndb_desc utility now provides
additional information about the partitioning of data
stored in MySQL Cluster. Beginning with MySQL Cluster NDB
option causes this program to include partition
in its output. Beginning with MySQL Cluster NDB 7.0.14,
option causes ndb_desc to include
information about data distribution (that is, which table
fragments are stored on which data nodes). Each of these
options also requires the use of the
Information about partition-to-node mappings can also be
obtained using the
Table::getFragmentNodes() method, also
added in MySQL Cluster NDB 7.0.14.
Replication attribute promotion and demotion.
Beginning with MySQL Cluster NDB 7.0.14, MySQL Cluster
Replication supports attribute promotion and demotion when
replicating between columns of different but similar types
on the master and the slave. For example, it is possible
to promote an
INT column on
the master to a
column on the slave, and to demote a
TEXT column to a
The implementation of type demotion distinguishes between
lossy and non-lossy type conversions, and their use on the
slave can be controlled by setting the
global server system variable.
For more information, see Attribute promotion and demotion (MySQL Cluster).