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.1  /  Changes in MySQL Cluster NDB 7.1.11 (5.1.51-ndb-7.1.11) (2011-02-25)

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

MySQL Cluster NDB 7.1.11 is a new release of MySQL Cluster, incorporating new features in the NDB storage engine and fixing recently discovered bugs in previous MySQL Cluster NDB 7.1 releases.

Obtaining MySQL Cluster NDB 7.1.  The latest MySQL Cluster NDB 7.1 binaries for supported platforms can be obtained from Source code for the latest MySQL Cluster NDB 7.1 release can be obtained from the same location. You can also access the MySQL Cluster NDB 7.1 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)).

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)

  • Added the --lossy-conversions option for ndb_restore, which makes it possible to enable attribute demotion when restoring a MySQL Cluster from an NDB native backup.

    For additional information about type conversions currently supported by MySQL Cluster for attribute promotion and demotion, see Replication of Columns Having Different Data Types.

  • Made it possible to enable multi-threaded building of ordered indexes during initial restarts, using the new TwoPassInitialNodeRestartCopy data node configuration parameter.

  • 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

  • This issue affects all previous MySQL Cluster NDB 7.1 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)

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