This release incorporates new features in the
NDBCLUSTER storage engine and fixes
recently discovered bugs in previous MySQL Cluster NDB 7.0
Obtaining MySQL Cluster NDB 7.0. The latest MySQL Cluster NDB 7.0 binaries for supported platforms can be obtained from http://dev.mysql.com/downloads/cluster/. Source code for the latest MySQL Cluster NDB 7.0 release can be obtained from the same location. You can also access the MySQL Cluster NDB 7.0 development source tree at https://code.launchpad.net/~mysql/mysql-server/mysql-cluster-7.0.
This release also incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.1, 6.2, 6.3, and 7.0 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.56 (see Changes in MySQL 5.1.56 (2011-03-01)).
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 now possible to add data nodes online to a running MySQL
Cluster without performing a rolling restart of the cluster or
starting data node processes with the
--nowait-nodes option. This can be
done by setting
65536 in the
config.ini file for
any data nodes that should be started at a later time, when
first starting the cluster. (It was possible to set
NodeGroup to this value
previously, but the management server failed to start.)
As part of this fix, a new data node configuration parameter
has been added. When the management server sees that there are
data nodes with no node group (that is, nodes for which
Nodegroup = 65536), it
milliseconds before treating these nodes as though they were
listed with the
option, and proceeds to start.
For more information, see Adding MySQL Cluster Data Nodes Online. (Bug #11766167, Bug #59213)
config_generation column has been added to
nodes table of the
ndbinfo database. By checking
this column, it is now possible to determine which version or
versions of the MySQL Cluster configuration file are in effect
on the data nodes. This information can be especially useful
when performing a rolling restart of the cluster to update its
Cluster API: A unique index operation is executed in two steps: a lookup on an index table, and an operation on the base table. When the operation on the base table failed, while being executed in a batch with other operations that succeeded, this could lead to a hanging execute, eventually timing out with Error 4012 (Request ndbd time-out, maybe due to high load or communication problems). (Bug #12315582)
A memory leak in
LGMAN, that leaked 8 bytes
of log buffer memory per 32k written, was introduced in MySQL
Cluster NDB 7.0.9, effecting all MySQL Cluster NDB 7.1 releases
as well as MySQL Cluster NDB 7.0.9 and later MySQL Cluster NDB
7.0 releases. (For example, when 128MB log buffer memory was
used, it was exhausted after writing 512GB to the undo log.)
This led to a GCP stop and data node failure.
References: This bug was introduced by Bug #47966.
When using ndbmtd, a MySQL Cluster configured with 32 data nodes failed to start correctly. (Bug #60943)
When performing a TUP scan with locks in parallel, and with a highly concurrent load of inserts and deletions, the scan could sometimes fail to notice that a record had moved while waiting to acquire a lock on it, and so read the wrong record. During node recovery, this could lead to a crash of a node that was copying data to the node being started, and a possible forced shutdown of the cluster.
Cluster API: Performing interpreted operations using a unique index did not work correctly, because the interpret bit was kept when sending the lookup to the index table.