This release incorporates new features in the
NDB storage engine and fixes
recently discovered bugs in MySQL Cluster NDB 7.0.14.
Obtaining MySQL Cluster NDB 7.0.15. The latest MySQL Cluster NDB 7.0 binaries for supported platforms can be obtained from http://dev.mysql.com/downloads/cluster/. Source code for the latest MySQL Cluster NDB 7.0 release can be obtained from the same location. You can also access the MySQL Cluster NDB 7.0 development source tree at https://code.launchpad.net/~mysql/mysql-server/mysql-cluster-7.0.
This release also incorporates all bugfixes and changes made in previous MySQL Cluster releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.44 (see Changes in MySQL 5.1.44 (2010-02-04)).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Important Change: The maximum number of attributes (columns plus indexes) per table has increased to 512.
--wait-nodes option has been added for
ndb_waiter. When this option is used, the
program waits only for the nodes having the listed IDs to reach
the desired state. For more information, see
ndb_waiter — Wait for MySQL Cluster to Reach a Given Status.
As part of this change, new methods relating to default values
have been added to the
Table classes in the NDB
API. For more information, see
option for ndb_restore. This option causes
ndb_restore to ignore any schema objects
which it does not recognize. Currently, this is useful chiefly
for restoring native backups made from a cluster running MySQL
Cluster NDB 7.0 to a cluster running MySQL Cluster NDB 6.3.
Added the MySQL Cluster management server option
--config-cache, which makes it
possible to enable and disable configuration caching. This
option is turned on by default; to disable configuration
caching, start ndb_mgmd with
--config-cache=0, or with
ndb_mgmd — The MySQL Cluster Management Server Daemon, for more
When attempting to create an
table on an SQL node that had not yet connected to a MySQL
Cluster management server since the SQL node's last
statement failed as expected, but with the unexpected Error 1495
For the partitioned engine it is necessary to define
(Bug #11747335, Bug #31853)
NDB tables until
creation of a table failed due to
NDB error 905 Out of
attribute records (increase MaxNoOfAttributes), then
restarting all management node and data node processes,
attempting to drop and re-create one of the tables failed with
the error Out of table records..., even
when sufficient table records were available.
References: See also Bug #52055. This bug is a regression of Bug #44294.
Creating a Disk Data table, dropping it, then creating an
in-memory table and performing a restart, could cause data node
processes to fail with errors in the
kernel block if the new table's internal ID was the same as
that of the old Disk Data table. This could occur because undo
log handling during the restart did not check that the table
having this ID was now in-memory only.
A table created while
enabled was not always stored to disk, which could lead to a
data node crash with Error opening DIH schema files
An internal buffer allocator used by
NDB has the form
alloc( and attempts to
wanted pages, but is
permitted to allocate a smaller number of pages, between
minimum. However, this allocator
could sometimes allocate fewer than
minimum pages, causing problems with
multi-threaded building of ordered indexes.
When compiled with support for
epoll but this
functionality is not available at runtime, MySQL Cluster tries
to fall back to use the
select() function in
its place. However, an extra
in the transporter registry code caused ndbd
to fail instead.
The value set for the ndb_mgmd option
--ndb-nodeid was not verified
prior to use as being within the permitted range (1 to 255,
inclusive), leading to a crash of the management server.
NDB truncated a column declared as
DECIMAL(65,0) to a length of 64.
Now such a column is accepted and handled correctly. In cases
where the maximum length (65) is exceeded,
NDB now raises an error instead of
NDB log handler failed, the memory
allocated to it was freed twice.
higher than 4G on 32-bit platforms caused
ndbd to crash, instead of failing gracefully
with an error.
(Bug #52536, Bug #50928)
When creating an index,
to check whether the internal ID allocated to the index was
within the permissible range, leading to an assertion. This
issue could manifest itself as a data node failure with
NDB error 707 (No more
table metadata records (increase MaxNoOfTables)),
when creating tables in rapid succession (for example, by a
script, or when importing from mysqldump),
even with a relatively high value for
MaxNoOfTables and a
relatively low number of tables.
ndb_restore did not raise any errors if hashmap creation failed during execution. (Bug #51434)
Specifying the node ID as part of the
--ndb-connectstring option to
mysqld was not handled correctly.
The fix for this issue includes the following changes:
Multiple occurrences of any of the mysqld
--ndb-nodeid are now handled
in the same way as with other MySQL server options, in that
the value set in the last occurrence of the option is the
value that is used by mysqld.
--ndb-nodeid is used,
its value overrides that of any
setting used in
example, starting mysqld with
--ndb-nodeid=3 now produces the same result as
starting it with
The 1024-character limit on the length of the connection
string is removed, and
--ndb-connectstring is now
handled in this regard in the same way as other
In the NDB API, a new constructor for
added which takes as its arguments a connection string and
the node ID to force the API node to use.
NDB did not distinguish correctly between table names differing
only by lettercase when
lower_case_table_names was set
ndb_mgm -e "ALL STATUS" erroneously reported
that data nodes remained in start phase 0 until they had
A buffer overrun in the handling of
DATE column values could cause
mysqlbinlog to fail when reading logs
containing certain combinations of DML statements on a table
DATE column followed by
dropping the table.
Replication failed after a restart of the slave SQL node, due to
an error in writing the
ALTER TABLE did not work
correctly where the name of the table, the database, or both
contained special characters, causing the MySQL server to crash.
References: See also Bug #53409, Bug #14959.
The performance of MySQL applications using non-persistent client connections was adversely affected due to many of these connections being kept waiting for an excessive length of time in cleanup phase while being closed. (Bug #48832)
The MySQL client library mishandled
EINPROGRESS errors for connections in
nonblocking mode. This could lead to replication failures on
hosts capable of resolving both IPv4 and IPv6 network addresses,
when trying to resolve
References: See also Bug #44344.