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.27 (5.1.56-ndb-7.0.27) (Not released)

Changes in MySQL Cluster NDB 7.0.27 (5.1.56-ndb-7.0.27) (Not released)

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.

Functionality Added or Changed

  • Important Change; Cluster Replication: Due to the existing layout of binary log row events, it was not possible to extend them with extra information which could be safely ignored by old slaves. New versions of the WRITE_ROW, UPDATE_ROW, and DELETE_ROW events have been implemented; these are referred to as Version 2 binary log events, and are intended for future enhancements such as improved conflict detection and resolution. The TABLE_MAP event is not affected.

    Version 2 binary log row events are not backward compatible, and cannot be read by older slaves. A new mysqld option --log-bin-use-v1-row-events can be used to force writing of Version 1 row events into the binary log. This can be used during upgrades to make a newer mysqld generate Version 1 binary log row events that can be read by older slaves.

  • It is now possible to filter the output from ndb_config so that it displays only system, data node, or connection parameters and values, using one of the options --system, --nodes, or --connections, respectively. In addition, it is now possible to specify from which data node the configuration data is obtained, using the --config_from_node option that is added in this release.

    For more information, see ndb_config — Extract MySQL Cluster Configuration Information. (Bug #11766870)

Bugs Fixed

  • Incompatible Change; Cluster API: Restarting a machine hosting data nodes, SQL nodes, or both, caused such nodes when restarting to time out while trying to obtain node IDs.

    As part of the fix for this issue, the behavior and default values for the NDB API Ndb_cluster_connection::connect() method have been improved. Due to these changes, the version number for the included NDB client library ( has been increased from 4.0.0 to 5.0.0. For NDB API applications, this means that as part of any upgrade, you must do both of the following:

    • Review and possibly modify any NDB API code that uses the connect() method, in order to take into account its changed default retry handling.

    • Recompile any NDB API applications using the new version of the client library.

    Also in connection with this issue, the default value for each of the two mysqld options --ndb-wait-connected and --ndb-wait-setup has been increased to 30 seconds (from 0 and 15, respectively). In addition, a hard-coded 30-second delay was removed, so that the value of --ndb-wait-connected is now handled correctly in all cases. (Bug #12543299)

  • Setting IndexMemory or sometimes DataMemory to 2 GB or higher could lead to data node failures under some conditions. (Bug #12873640)

  • When replicating DML statements with IGNORE between clusters, the number of operations that failed due to nonexistent keys was expected to be no greater than the number of defined operations of any single type. Because the slave SQL thread defines operations of multiple types in batches together, code which relied on this assumption could cause mysqld to fail. (Bug #12859831)

  • The maximum effective value for the OverloadLimit configuration parameter was limited by the value of SendBufferMemory. Now the value set for OverloadLimit is used correctly, up to this parameter's stated maximum (4G). (Bug #12712109)

  • AUTO_INCREMENT values were not set correctly for INSERT IGNORE statements affecting NDB tables. This could lead such statements to fail with Got error 4350 'Transaction already aborted' from NDBCLUSTER when inserting multiple rows containing duplicate values. (Bug #11755237, Bug #46985)

  • When failure handling of an API node takes longer than 300 seconds, extra debug information is included in the resulting output. In cases where the API node's node ID was greater than 48, these extra debug messages could lead to a crash, and confuing output otherwise. This was due to an attempt to provide information specific to data nodes for API nodes as well. (Bug #62208)

  • In rare cases, a series of node restarts and crashes during restarts could lead to errors while reading the redo log. (Bug #62206)

  • Cluster Replication: A transaction that updated many (thousands of) rows executed properly on the master but failed on the slave with the error Lock wait timeout exceeded.... (Bug #12974714)