This is a new Beta development release, incorporating new
features in the
engine and fixing recently discovered bugs in previous MySQL
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 ftp://ftp.mysql.com/pub/mysql/download/cluster_telco/mysql-5.1.30-ndb-6.4.0/.
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 http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Functionality Added or Changed
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 (
have been added for this purpose. For more information, see
MySQL Cluster Configuration Files, and
ndb_mgmd — The MySQL Cluster Management Server Daemon.
It is now possible while in Single User Mode to restart all data
ALL RESTART in the management
client. Restarting of individual nodes while in Single User Mode
remains not permitted.
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
SNAPSHOTEND in the management client. See
Using The MySQL Cluster Management Client to Create a Backup,
for more information.
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 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.
methods have been added to help in diagnosing problems with NDB
API client connections. The
method tells whether or not the latest connection attempt
succeeded; if the attempt failed,
provides an error message giving the reason.
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)
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)
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)
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
node_id is the
management node's node ID:
Shutting down MGM node
node_idfor restart Node
node_idis being restarted ndb_mgm>
A data node failure when
NoOfReplicas was greater
than 2 caused all cluster SQL nodes to crash.
Partitioning: A query on a user-partitioned table caused MySQL to crash, where the query had the following characteristics:
WHERE clause referenced
an indexed column that was also in the partitioning key.
WHERE clause included a
value found in the partition.
WHERE clause used the
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 used an explicit or
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:
SELECT * FROM
tableWHERE a <
constantORDER BY a;
SELECT * FROM
tableWHERE a <>
constantORDER BY a;
References: This bug was introduced by Bug #30573, Bug #33257, Bug #33555.