This is a bugfix release, fixing recently discovered bugs in the previous MySQL Cluster NDB 6.3 release.
MySQL Cluster NDB 6.3 no longer in development.
MySQL Cluster NDB 6.3 is no longer being actively developed;
if you are using a MySQL Cluster NDB 6.3 release, you should
upgrade to the latest version of MySQL Cluster, which is
Obtaining MySQL Cluster NDB 6.3. You can download MySQL Cluster NDB 6.3.20 source code and binaries for supported platforms from http://dev.mysql.com/downloads/cluster/.
This release 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.30 (see Changes in MySQL 5.1.30 (2008-11-14, General Availability)).
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
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.
Statements of the form
UPDATE ... ORDER BY ...
LIMIT run against
NDBCLUSTER tables failed to update
all matching rows, or failed with the error Can't
find record in
SHOW TABLES repeatedly could cause
NDBCLUSTER tables to be dropped.
Start phase reporting was inconsistent between the management client and the cluster log. (Bug #39667)
If a transaction was aborted during the handling of a data node failure, this could lead to the later handling of an API node failure not being completed. (Bug #41214)
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>
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;
This bug was introduced in MySQL Cluster NDB 6.3.19. (Bug #40954)
References: This bug was introduced by Bug #30573, Bug #33257, Bug #33555.
Issuing the statement
CHANGE MASTER TO ...
using a value for
period outside the permitted range
caused the slave to crash.
Disk Data: This improves on a previous fix for this issue that was made in MySQL Cluster 6.3.8. (Bug #37116)
References: See also Bug #29186.
When creating a scan using an
NdbScanFilter object, it was
possible to specify conditions against a
column, but the correct rows were not returned when the scan was
As part of this fix, 4 new comparison operators have been
implemented for use with scans on
For more information about these operators, see
Equivalent methods are now also defined for
NdbInterpretedCode; for more
NdbInterpretedCode Bitwise Comparison Operations.