This release incorporates new features in the
NDBCLUSTER storage engine and fixes
recently discovered bugs in previous MySQL Cluster NDB 7.0
Obtaining MySQL Cluster NDB 7.0. 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.51 (see Changes in MySQL 5.1.51 (2010-09-10)).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Functionality Added or Changed
now provides disk usage as well as memory usage information for
Disk Data tables. Also,
formerly did not show any statistics for
NDB tables. Now the
DATA_FREE columns contain correct information
for the table's partitions.
option is added for ndb_restore, which makes
it possible to restore to a database having a different name
from that of the database in the backup.
For more information, see ndb_restore — Restore a MySQL Cluster Backup. (Bug #54327)
The NDB kernel now implements a number of statistical counters
relating to actions performed by or affecting
Ndb objects, such as starting,
closing, or aborting transactions; primary key and unique key
operations; table, range, and pruned scans; blocked threads
waiting for various operations to complete; and data and events
sent and received by
These NDB API counters are incremented inside the NDB kernel
whenever NDB API calls are made or data is sent to or received
by the data nodes. mysqld exposes these
counters as system status variables; their values can be read in
the output of
SHOW STATUS, or by
table in the
INFORMATION_SCHEMA database. By
comparing the values of these status variables prior to and
following the execution of SQL statements that act on
NDB tables, you can observe the
corresponding actions taken on the NDB API level, which can be
beneficial for monitoring and performance tuning of MySQL
Important Note: Due to an error in merging the original fix, it did not appear MySQL Cluster NDB 7.0.21; this oversight has been corrected in the current release. (Bug #58256)
This issue affects all previous MySQL Cluster NDB 7.0 releases. (Bug #60045)
caused multi-threaded index building to occur on the master node
Successive queries on the
counters table from the same
SQL node returned unchanging results. To fix this issue, and to
prevent similar issues from occurring in the future,
ndbinfo tables are now
excluded from the query cache.
When attempting to create a table on a MySQL Cluster with many
standby data nodes (setting
config.ini for the nodes that should wait,
starting the nodes that should start immediately with the
--nowait-nodes option, and using
CREATE TABLE statement's
MAX_ROWS option), mysqld
miscalculated the number of fragments to use. This caused the
CREATE TABLE to fail.
CREATE TABLE failure caused
by this issue in turn prevented any further attempts to create
the table, even if the table structure was simplified or
changed in such a way that the attempt should have succeeded.
This “ghosting” issue is handled in Bug #59756.
CREATE TABLE statement
failed due to
NDB error 1224
(Too many fragments), it was not possible
to create the table afterward unless either it had no ordered
indexes, or a
statement was issued first, even if the subsequent
CREATE TABLE was valid and should
otherwise have succeeded.
References: See also Bug #59751.
NDB sometimes treated a simple (not
unique) ordered index as unique.
The logic used in determining whether to collapse a range to a
simple equality was faulty. In certain cases, this could cause
NDB to treat a range as if it were
a primary key lookup when determining the query plan to be used.
Although this did not affect the actual result returned by the
query, it could in such cases result in inefficient execution of
queries due to the use of an inappropriate query plan.
When a query used multiple references to or instances of the
same physical tables,
NDB failed to
recognize these multiple instances as different tables; in such
NDB could incorrectly use
condition pushdown on a condition referring to these other
instances to be pushed to the data nodes, even though the
condition should have been rejected as unpushable, leading to
When an NDBAPI client application was waiting for more scan
results after calling
the calling thread sometimes woke up even if no new batches for
any fragment had arrived, which was unnecessary, and which could
have a negative impact on the application's performance.
during a node restart, it was possible to get a spurious error
711 (System busy with node restart, schema operations
not allowed when a node is starting).
OUTER JOIN query using
return an incorrect result.
(Bug #58490, Bug #11765513)
col_name IS NULL
For a query that used a subquery that included
BY inside a
< ANY() construct,
no rows were returned when there should have been.
(Bug #56690, Bug #11763918)
The “greedy” query plan optimizer failed to consider the size of intermediate query results when calculating the cost of a query. This could result in slowly executing queries when there are much faster execution plans available. (Bug #59326, Bug #11766256)