Documentation Home
MySQL NDB Cluster 6.1 - 7.1 Release Notes
Download these Release Notes
PDF (US Ltr) - 3.0Mb
PDF (A4) - 3.0Mb

MySQL NDB Cluster 6.1 - 7.1 Release Notes  /  Changes in MySQL Cluster NDB 7.0  /  Changes in MySQL Cluster NDB 7.0.22 (5.1.51-ndb-7.0.22) (2011-02-25)

Changes in MySQL Cluster NDB 7.0.22 (5.1.51-ndb-7.0.22) (2011-02-25)

This release incorporates new features in the NDB storage engine and fixes recently discovered bugs in previous MySQL Cluster NDB 7.0 releases.

Obtaining MySQL Cluster NDB 7.0.  The latest MySQL Cluster NDB 7.0 binaries for supported platforms can be obtained from 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

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 for more details about the individual bugs fixed in this version.

Functionality Added or Changed

  • Disk Data: The INFORMATION_SCHEMA.TABLES table now provides disk usage as well as memory usage information for Disk Data tables. Also, INFORMATION_SCHEMA.PARTITIONS, formerly did not show any statistics for NDB tables. Now the TABLE_ROWS, AVG_ROW_LENGTH, DATA_LENGTH, MAX_DATA_LENGTH, and DATA_FREE columns contain correct information for the table's partitions.

  • A new --rewrite-database 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 NDBCLUSTER. 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 querying the SESSION_STATUS or GLOBAL_STATUS 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 Cluster.

    For more information, see NDB API Statistics Counters and Variables, as well as MySQL Cluster Status Variables.

Bugs Fixed

  • 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)

  • ndb_restore --rebuild-indexes caused multi-threaded index building to occur on the master node only. (Bug #59920)

  • 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. (Bug #59831)

  • When a 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 DROP TABLE statement was issued first, even if the subsequent CREATE TABLE was valid and should otherwise have succeeded. (Bug #59756)

    References: See also: Bug #59751.

  • When attempting to create a table on a MySQL Cluster with many standby data nodes (setting Nodegroup=65536 in config.ini for the nodes that should wait, starting the nodes that should start immediately with the --nowait-nodes option, and using the CREATE TABLE statement's MAX_ROWS option), mysqld miscalculated the number of fragments to use. This caused the CREATE TABLE to fail.


    The 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.

    (Bug #59751)

    References: See also: Bug #59756.

  • NDB sometimes treated a simple (not unique) ordered index as unique. (Bug #59519)

  • 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. (Bug #59517)

  • 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 a case, 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 invalid results. (Bug #58791)

  • Cluster API: When calling NdbEventOperation::execute() 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). (Bug #59723)

  • Cluster API: When an NDBAPI client application was waiting for more scan results after calling NdbScanOperation::nextResult(), 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. (Bug #52298)

  • 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)

  • An OUTER JOIN query using WHERE col_name IS NULL could return an incorrect result. (Bug #58490, Bug #11765513)

  • For a query that used a subquery that included GROUP BY inside a < ANY() construct, no rows were returned when there should have been. (Bug #56690, Bug #11763918)