MySQL Cluster NDB 7.3.2 is the first GA release of MySQL Cluster,
based on MySQL Server 5.6 and including new features in version
7.3 of the
NDB storage engine, as
well as fixing recently discovered bugs in previous MySQL Cluster
Obtaining MySQL Cluster NDB 7.3. MySQL Cluster NDB 7.3 source code and binaries can be obtained from http://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL Cluster NDB 7.3, see MySQL Cluster Development in MySQL Cluster NDB 7.3.
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.6 through MySQL 5.6.11 (see Changes in MySQL 5.6.11 (2013-04-18)).
The MySQL Cluster installer for Windows provided a nonfunctional
option to install debug symbols (contained in
*.pdb files). This option has been removed
from the installer.
You can obtain the
*.pdb debug files for
a given MySQL Cluster release from the Windows
.zip archive for the same release, such
(Bug #16748308, Bug #69112)
mysql_upgrade failed when upgrading from
MySQL Cluster NDB 7.1.26 to MySQL Cluster NDB 7.2.13 when it
attempted to invoke a stored procedure before the
mysql.proc table had been upgraded.
References: This bug is a regression of Bug #16226274.
The planned or unplanned shutdown of one or more data nodes
while reading table data from the
ndbinfo database caused a
DROP TABLE while
DBDIH was updating table checkpoint
information subsequent to a node failure could lead to a data
In certain cases, when starting a new SQL node, mysqld failed with Error 1427 Api node died, when SUB_START_REQ reached node. (Bug #16840741)
Failure to use container classes specific
NDB during node failure handling
could cause leakage of commit-ack markers, which could later
lead to resource shortages or additional node crashes.
Use of an uninitialized variable employed in connection with
error handling in the
DBLQH kernel block
could sometimes lead to a data node crash or other stability
issues for no apparent reason.
A race condition in the time between the reception of a
execNODE_FAILREP signal by the
QMGR kernel block and its reception by the
blocks could lead to data node crashes during shutdown.
CLUSTERLOG command (see
Commands in the MySQL Cluster Management Client) caused
ndb_mgm to crash on Solaris SPARC systems.
On Solaris SPARC platforms, batched key access execution of some joins could fail due to invalid memory access. (Bug #16818575)
NDB tables had foreign key
references to each other, it was necessary to drop the tables in
the same order in which they were created.
The duplicate weedout algorithm introduced in MySQL 5.6
evaluates semi-joins such as subqueries using
IN) by first performing a normal join between
the outer and inner table which may create duplicates of rows
form the outer (and inner) table and then removing any duplicate
result rows from the outer table by comparing their primary key
values. Problems could arise when
VARCHAR values using their
maximum length, resulting in a binary key image which contained
garbage past the actual lengths of the
VARCHAR values, which meant that multiple
instances of the same key were not binary-identical as assumed
by the MySQL server.
To fix this problem,
NDB now zero-pads such
values to the maximum length of the column so that copies of the
same key are treated as identical by the weedout process.
DROP DATABASE failed to work
correctly when executed against a database containing
NDB tables joined by foreign key
constraints (and all such tables being contained within this
database), leaving these tables in place while dropping the
remaining tables in the database and reporting failure.
(Bug #16692652, Bug #69008)
firstmatch=on with the
variable, pushed joins could return too many rows.
A variable used by the batched key access implementation was not
NDB as expected.
This could cause a “batch full” condition to be
reported after only a single row had been batched, effectively
disabling batching altogether and leading to an excessive number
of round trips between mysqld and
When started with
-f) option, ndb_mgmd
removed the old configuration cache before verifying the
configuration file. Now in such cases,
ndb_mgmd first checks for the file, and
continues with removing the configuration cache only if the
configuration file is found and is valid.
Creating more than 32 hash maps caused data nodes to fail.
Usually new hashmaps are created only when performing
reorganzation after data nodes have been added or when explicit
partitioning is used, such as when creating a table with the
MAX_ROWS option, or using
BY KEY() PARTITIONS .
foreign_key_checks = 0
had no effect on the handling of
NDB tables. Now, doing so causes
such checks of foreign key constraints to be
suspended—that is, has the same effect on
NDB tables as it has on
(Bug #14095855, Bug #16286309)
References: See also Bug #16286164.
ALTER LOGFILE GROUP, and
ALTER TABLESPACE failed with a
syntax error when
INITIAL_SIZE was specified
using letter abbreviations such as
G. In addition,
LOGFILE GROUP failed when
UNDO_BUFFER_SIZE, or both options were
specified using letter abbreviations.
(Bug #13116514, Bug #16104705, Bug #62858)
For each log event retrieved using the MGM API, the log event
simply cast to an
enum type, which resulted
in invalid category values. Now an offset is added to the
category following the cast to ensure that the value does not
fall out of the allowed range.
This change was reverted by the fix for Bug #18354165. See the
MySQL Cluster API Developer documentation for
method performs a
malloc() if no buffer is
provided for it to use. However, it was assumed that the memory
thus returned would always be suitably aligned, which is not
always the case. Now when
malloc() provides a
buffer to this method, the buffer is aligned after it is
allocated, and before it is used.
ClusterJ: ClusterJ now provides partial support for MySQL date and time data types with fractional seconds (see Date and Time Type Overview), as shown in the following table:
|ClusterJ Class||MySQL Data Types||Precision|