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.25 (5.1.56-ndb-7.0.25) (2011-05-24)

Changes in MySQL Cluster NDB 7.0.25 (5.1.56-ndb-7.0.25) (2011-05-24)

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.56 (see Changes in MySQL 5.1.56 (2011-03-01)).


Please refer to our bug database at for more details about the individual bugs fixed in this version.

Bugs Fixed

  • The internal Ndb_getinaddr() function has been rewritten to use getaddrinfo() instead of my_gethostbyname_r() (which is removed in a later version of the MySQL Server). (Bug #12542120)

  • Two unused test files in storage/ndb/test/sql contained incorrect versions of the GNU Lesser General Public License. The files and the directory containing them have been removed. (Bug #11810156)

    References: See also: Bug #11810224.

  • Error 1302 gave the wrong error message (Out of backup record). This has been corrected to A backup is already running. (Bug #11793592)

  • When using two management servers, issuing in an ndb_mgm client connected to one management server a STOP command for stopping the other management server caused Error 2002 (Stop failed ... Send to process or receive failed.: Permanent error: Application error), even though the STOP command actually succeeded, and the second ndb_mgmd was shut down. (Bug #61147)

  • In ndbmtd, a node connection event is detected by a CMVMI thread which sends a CONNECT_REP signal to the QMGR kernel block. In a few isolated circumstances, a signal might be transferred to QMGR directly by the NDB transporter before the CONNECT_REP signal actually arrived. This resulted in reports in the error log with status Temporary error, restart node, and the message Internal program error. (Bug #61025)

  • Renaming a table having BLOB or TEXT columns (or both) to another database caused the SQL node to crash, and the table to become inaccessible afterwards. (Bug #60484)

  • Under heavy loads with many concurrent inserts, temporary failures in transactions could occur (and were misreported as being due to NDB Error 899 Rowid already allocated). As part of the fix for this issue, NDB Error 899 has been reclassified as an internal error, rather than as a temporary transaction error. (Bug #56051, Bug #11763354)

  • Disk Data: Accounting for MaxNoOfOpenFiles was incorrect with regard to data files in MySQL Cluster Disk Data tablespaces. This could lead to a crash when MaxNoOfOpenFiles was exceeded. (Bug #12581213)

  • Cluster Replication: Operations that updated unique keys of NDB tables could cause duplicate key errors when trying to execute the binary log. (Previously, row events in the binary log were ordered according to the partitioning of the base table, which could differ in order within the epoch for that in which they were executed.

    To keep this from happening, unique keys are now updated in deferred mode, meaning that all table rows are updated before any unique indexes are checked. Thus, the order of the row updates is no longer important.

    You should be aware that deferring constraint checking in this way is currently supported only by NDB, and thus only for replication between NDB tables on both the master and the slave. You cannot replicate updates of unique keys successfully when replicating from NDB to a different storage engine such as MyISAM or InnoDB. (Bug #47952, Bug #11756082)