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 6.4.0 (5.1.30-ndb-6.4.0) (2008-12-22, Beta)

Changes in MySQL Cluster NDB 6.4.0 (5.1.30-ndb-6.4.0) (2008-12-22, Beta)

This is a new Beta development release, incorporating new features in the NDB storage engine and fixing recently discovered bugs in previous MySQL Cluster releases.

Obtaining MySQL Cluster NDB 6.4.0.  MySQL Cluster NDB 6.4.0 is a source-only release. You can obtain the source code from

This Beta release incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.1, 6.2, and 6.3 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.30 (see Changes in MySQL 5.1.30 (2008-11-14, General Availability)).


This Beta release, as any other pre-production release, should not be installed on production level systems or systems with critical data. Please refer to our bug database at for more details about the individual bugs fixed in this version.

Functionality Added or Changed

  • Important Change: MySQL Cluster now caches its configuration data. This means that, by default, the management server only reads the global configuration file (usually named config.ini) the first time that it is started, and does not automatically re-read the this file when restarted. This behavior can be controlled using new management server options (--config-dir, --initial, and --reload) that have been added for this purpose. For more information, see MySQL Cluster Configuration Files, and ndb_mgmd — The MySQL Cluster Management Server Daemon.

  • Important Change: Send buffer memory is now allocated dynamically from a shared memory pool, which means that the size of the send buffer can be adjusted as necessary.

    The data node configuration parameters TotalSendBufferMemory, ReservedSendBufferMemory, and the TCP configuration paramater OverLoadLimit have been added to configure this dynamic allocation. In addition, the behavior and use of the SendBufferMemory TCP configuration parameter has changed. See Configuring MySQL Cluster Send Buffer Parameters, for more information.

  • It is now possible while in Single User Mode to restart all data nodes using ALL RESTART in the management client. Restarting of individual nodes while in Single User Mode remains not permitted. (Bug #31056)

  • It is now possible to add data nodes to a MySQL Cluster online—that is, to a running MySQL Cluster without shutting it down.

    For information about the procedure for adding data nodes online, see Adding MySQL Cluster Data Nodes Online.

  • A multi-threaded version of the MySQL Cluster data node daemon is now available. The multi-threaded ndbmtd binary is similar to ndbd and functions in much the same way, but is intended for use on machines with multiple CPU cores.

    For more information, see ndbmtd — The MySQL Cluster Data Node Daemon (Multi-Threaded).

  • It is now possible when performing a cluster backup to determine whether the backup matches the state of the data when the backup began or when it ended, using the new START BACKUP options SNAPSHOTSTART and SNAPSHOTEND in the management client. See Using The MySQL Cluster Management Client to Create a Backup, for more information.

  • Cluster API: Two new Ndb_cluster_connection methods have been added to help in diagnosing problems with NDB API client connections. The get_latest_error() method tells whether or not the latest connection attempt succeeded; if the attempt failed, get_latest_error_msg() provides an error message giving the reason.

Bugs Fixed

  • API nodes disconnected too agressively from cluster when data nodes were being restarted. This could sometimes lead to the API node being unable to access the cluster at all during a rolling restart. (Bug #41462)

  • When long signal buffer exhaustion in the ndbd process resulted in a signal being dropped, the usual handling mechanism did not take fragmented signals into account. This could result in a crash of the data node because the fragmented signal handling mechanism was not able to work with the missing fragments. (Bug #39235)

  • The failure of a master node during a DDL operation caused the cluster to be unavailable for further DDL operations until it was restarted; failures of nonmaster nodes during DLL operations caused the cluster to become completely inaccessible. (Bug #36718)

  • Status messages shown in the management client when restarting a management node were inappropriate and misleading. Now, when restarting a management node, the messages displayed are as follows, where node_id is the management node's node ID:

    ndb_mgm> node_id RESTART
    Shutting down MGM node node_id for restart
    Node node_id is being restarted

    (Bug #29275)

  • A data node failure when NoOfReplicas was greater than 2 caused all cluster SQL nodes to crash. (Bug #18621)

  • Partitioning: A query on a user-partitioned table caused MySQL to crash, where the query had the following characteristics:

    • The query's WHERE clause referenced an indexed column that was also in the partitioning key.

    • The query's WHERE clause included a value found in the partition.

    • The query's WHERE clause used the < or <> operators to compare with the indexed column's value with a constant.

    • The query used an ORDER BY clause, and the same indexed column was used in the ORDER BY clause.

    • The ORDER BY clause used an explicit or implicit ASC sort priority.

    Two examples of such a query are given here, where a represents an indexed column used in the table's partitioning key:

    1. SELECT * FROM table WHERE a < constant ORDER BY a;

    2. SELECT * FROM table WHERE a <> constant ORDER BY a;

    (Bug #40954)

    References: This issue is a regression of: Bug #30573, Bug #33257, Bug #33555.