This is a bugfix release, fixing recently discovered bugs in the previous MySQL Cluster NDB 6.3 release.
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.34 (see Changes in MySQL 5.1.34 (2009-04-02)).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Two new server status variables
Ndb_scan_count gives the
number of scans executed since the cluster was last started.
the number of scans for which
NDBCLUSTER was able to use
partition pruning. Together, these variables can be used to help
determine in the MySQL server whether table scans are pruned by
The ndb_config utility program can now
provide an offline dump of all MySQL Cluster configuration
parameters including information such as default and permitted
values, brief description, and applicable section of the
config.ini file. A dump in text format is
produced when running ndb_config with the new
--configinfo option, and in XML format when the
--configinfo --xml are used together.
For more information and examples, see
ndb_config — Extract MySQL Cluster Configuration Information.
Important Change; Partitioning:
User-defined partitioning of an
NDBCLUSTER table without any
primary key sometimes failed, and could cause
mysqld to crash.
Now, if you wish to create an
NDBCLUSTER table with user-defined
partitioning, the table must have an explicit primary key, and
all columns listed in the partitioning expression must be part
of the primary key. The hidden primary key used by the
NDBCLUSTER storage engine is not
sufficient for this purpose. However, if the list of columns is
empty (that is, the table is defined using
[LINEAR] KEY()), then no explicit primary key is
This change does not effect the partitioning of tables using any
storage engine other than
pkg installer for MySQL Cluster on
Solaris did not perform a complete installation due to an
invalid directory reference in the postinstall script.
When ndb_config could not find the file
referenced by the
--config-file option, it
tried to read
my.cnf instead, then failed
with a misleading error message.
When a data node was down so long that its most recent local checkpoint depended on a global checkpoint that was no longer restorable, it was possible for it to be unable to use optimized node recovery when being restarted later. (Bug #44844)
References: See also Bug #26913.
did not output any entries for the
parameter. In addition, the default listed for
MaxNoOfFiles was outside the permitted range
References: See also Bug #44685, Bug #44746.
The output of ndb_config
did not provide information about all sections of the
References: See also Bug #44746, Bug #44749.
Inspection of the code revealed that several assignment
=) were used in place of
comparison operators (
References: See also Bug #44570.
It was possible for NDB API applications to insert corrupt data into the database, which could subquently lead to data node crashes. Now, stricter checking is enforced on input data for inserts and updates. (Bug #44132)
ndb_restore failed when trying to restore data on a big-endian machine from a backup file created on a little-endian machine. (Bug #44069)
ndberror.c contained a C++-style
comment, which caused builds to fail with some C compilers.
When trying to use a data node with an older version of the management server, the data node crashed on startup. (Bug #43699)
In some cases, data node restarts during a system restart could fail due to insufficient redo log space. (Bug #43156)
NDBCLUSTER did not build correctly
on Solaris 9 platforms.
References: See also Bug #39036, Bug #39038.
The output of ndbd
did not provide clear information about the program's
It was theoretically possible for the value of a nonexistent
column to be read as
NULL, rather than
causing an error.
Disk Data: This fix supersedes and improves on an earlier fix made for this bug in MySQL 5.1.18. (Bug #24521)
Cluster Replication: A failure when setting up replication events could lead to subsequent data node failures. (Bug #44915)