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.1 through
MySQL 5.1.34 (see Changes in MySQL 5.1.34 (2009-04-02)).

Note

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

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
options --configinfo --xml are used together.
For more information and examples, see
ndb_config — Extract MySQL Cluster Configuration Information.

Bugs Fixed

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 PARTITION BY
[LINEAR] KEY()), then no explicit primary key is
required.

This change does not effect the partitioning of tables using any
storage engine other than
NDBCLUSTER.
(Bug #40709)

Important Change:
Previously, the configuration parameter
NoOfReplicas had no
default value. Now the default for
NoOfReplicas is 2, which
is the recommended value in most settings.
(Bug #44746)

Important Note:
It was not possible to perform an online upgrade from any MySQL
Cluster NDB 6.x release to MySQL Cluster NDB 7.0.5 or any to
earlier MySQL Cluster NDB 7.0 release.

When a data node had written its GCI marker to the first page of
a megabyte, and that node was later killed during restart after
having processed that page (marker) but before completing a LCP,
the data node could fail with file system errors.
(Bug #44952)

References: See also Bug #42564, Bug #44291.

When restarting a data nodes, management and API nodes
reconnecting to it failed to re-use existing ports that had
already been dynamically allocated for communications with that
data node.
(Bug #44866)

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.
(Bug #44846)

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.

Online upgrades to MySQL Cluster NDB 7.0 from a MySQL Cluster
NDB 6.3 release could fail due to changes in the handling of key
lengths and unique indexes during node recovery.
(Bug #44827)

ndb_config
--xml
did not output any entries for the HostName
parameter. In addition, the default listed for
MaxNoOfFiles was outside the permitted range
of values.
(Bug #44749)

References: See also Bug #44685, Bug #44746.

The output of ndb_config
--xml
did not provide information about all sections of the
configuration file.
(Bug #44685)

References: See also Bug #44746, Bug #44749.

Use of __builtin_expect() had the side effect
that compiler warnings about misuse of =
(assignment) instead of == in comparisons
were lost when building in debug mode. This is no longer
employed when configuring the build with the
--with-debug option.
(Bug #44570)

References: See also Bug #44567.

Inspection of the code revealed that several assignment
operators (=) were used in place of
comparison operators (==) in
DbdihMain.cpp.
(Bug #44567)

References: See also Bug #44570.

When using large numbers of configuration parameters, the
management server took an excessive amount of time (several
minutes or more) to load these from the configuration cache when
starting. This problem occurred when there were more than 32
configuration parameters specified, and became progressively
worse with each additional multiple of 32 configuration
parameters.
(Bug #44488)

Building the MySQL Cluster NDB 7.0 tree failed when using the
icc compiler.
(Bug #44310)

Signals providing node state information
(NODE_STATE_REP and
CHANGE_NODE_STATE_REQ) were not propagated to
all blocks of ndbmtd. This could cause the
following problems:

Inconsistent redo logs when performing a graceful shutdown;

Data nodes crashing when later restarting the cluster, data
nodes needing to perform node recovery during the system
restart, or both.

(Bug #44291)

References: See also Bug #42564.

An NDB internal timing function did not work correctly on
Windows and could cause mysqld to fail on
some AMD processors, or when running inside a virtual machine.
(Bug #44276)

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)

Repeated starting and stopping of data nodes could cause
ndb_mgmd to fail. This issue was observed on Solaris/SPARC.
(Bug #43974)

A number of incorrectly formatted output strings in the source
code caused compiler warnings.
(Bug #43878)

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)

The output of ndbd --help
did not provide clear information about the program's
--initial and --initial-start
options.
(Bug #28905)

It was theoretically possible for the value of a nonexistent
column to be read as NULL, rather than
causing an error.
(Bug #27843)

Disk Data:
During a checkpoint, restore points are created for both the
on-disk and in-memory parts of a Disk Data table. Under certain
rare conditions, the in-memory restore point could include or
exclude a row that should have been in the snapshot. This would
later lead to a crash during or following recovery.

This issue was somewhat more likely to be encountered when using
ndbmtd.
(Bug #41915)

References: See also Bug #47832.

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)