This is a bugfix release, fixing recently discovered bugs in the previous MySQL Cluster NDB 6.3 release.
Obtaining MySQL Cluster NDB 6.3. You can download the latest MySQL Cluster NDB 6.3 source code and binaries for supported platforms from http://dev.mysql.com/downloads/select.php?id=14.
This release incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.3 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.28 (see Section C.1.24, “Changes in MySQL 5.1.28 (28 August 2008)”).
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:
It is no longer a requirement for database autodiscovery that an
SQL node already be connected to the cluster at the time that a
database is created on another SQL node. It is no longer
necessary to issue CREATE
DATABASE
(or
CREATE
SCHEMA
) statements on an SQL node joining the cluster
after a database is created in order for the new SQL node to see
the database and any NDCLUSTER
tables that it
contains.
(Bug#39612)
Bugs fixed:
When a transaction included a multi-row insert to an
NDBCLUSTER
table that caused a
constraint violation, the transaction failed to roll back.
(Bug#395638)
Starting the MySQL Server with the
--ndbcluster
option plus an
invalid command-line option (for example, using
mysqld --ndbcluster
--foobar
) caused it to hang while shutting down the
binlog thread.
(Bug#39635)
Dropping and then re-creating a database on one SQL node caused other SQL nodes to hang. (Bug#39613)
Setting a low value of MaxNoOfLocalScans
(< 100) and performing a large number of (certain) scans
could cause the Transaction Coordinator to run out of scan
fragment records, and then crash. Now when this resource is
exhausted, the cluster returns Error 291 (Out of
scanfrag records in TC (increase MaxNoOfLocalScans))
instead.
(Bug#39549)
Creating a unique index on an
NDBCLUSTER
table caused a memory
leak in the NDB
subscription
manager (SUMA
) which could lead to mysqld
hanging, due to the fact that the resource shortage was not
reported back to the NDB
kernel
correctly.
(Bug#39518)
See also Bug#39450.
Embedded libmysqld with
NDB
did not drop table events.
(Bug#39450)
Unique identifiers in tables having no primary key were not
cached. This fix has been observed to increase the efficiency of
INSERT
operations on such tables
by as much as 50%.
(Bug#39267)
When restarting a data node, an excessively long shutodwn message could cause the node process to crash. (Bug#38580)
After a forced shutdown and initial restart of the cluster, it
was possible for SQL nodes to retain .frm
files corresponding to NDBCLUSTER
tables that had been dropped, and thus to be unaware that these
tables no longer existed. In such cases, attempting to re-create
the tables using CREATE TABLE IF NOT EXISTS
could fail with a spurious Table ... doesn't
exist error.
(Bug#37921)
A statement of the form DELETE FROM
or table
WHERE
primary_key
=value
UPDATE
where there was no row whose primary key column had the stated
table
WHERE
primary_key
=value
value
appeared to succeed, with the
server reporting that 1 row had been changed.
This issue was only known to affect MySQL Cluster NDB 6.3.11 and later NDB 6.3 versions. (Bug#37153)
Cluster Replication: In some cases, dropping a database on the master could cause table logging to fail on the slave, or, when using a debug build, could cause the slave mysqld to fail completely. (Bug#39404)
Cluster API:
Passing a value greater than 65535 to
NdbInterpretedCode::add_val()
and
NdbInterpretedCode::sub_val()
caused these
methods to have no effect.
(Bug#39536)
User Comments
Add your own comment.