MySQL Cluster NDB 7.1.16 is a new release of MySQL Cluster,
incorporating new features in the
NDB storage engine and fixing
recently discovered bugs in previous MySQL Cluster NDB 7.1
Obtaining MySQL Cluster NDB 7.1. The latest MySQL Cluster NDB 7.1 binaries for supported platforms can be obtained from http://dev.mysql.com/downloads/cluster/. Source code for the latest MySQL Cluster NDB 7.1 release can be obtained from the same location. You can also access the MySQL Cluster NDB 7.1 development source tree at https://code.launchpad.net/~mysql/mysql-server/mysql-cluster-7.1.
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.56 (see Changes in MySQL 5.1.56 (2011-03-01)).
Functionality Added or Changed
Important Change; Cluster Replication:
Due to the existing layout of binary log row events, it was not
possible to extend them with extra information which could be
safely ignored by old slaves. New versions of the
DELETE_ROW events have been implemented;
these are referred to as “Version 2” binary log
events, and are intended for future enhancements such as
improved conflict detection and resolution. The
TABLE_MAP event is not affected.
Version 2 binary log row events are not backward compatible, and
cannot be read by older slaves. A new mysqld
be used to force writing of Version 1 row events into the binary
log. This can be used during upgrades to make a newer
mysqld generate Version 1 binary log row
events that can be read by older slaves.
It is now possible to filter the output from
ndb_config so that it displays only system,
data node, or connection parameters and values, using one of the
In addition, it is now possible to specify from which data node
the configuration data is obtained, using the
that is added in this release.
For more information, see ndb_config — Extract MySQL Cluster Configuration Information. (Bug #11766870)
Added two new conflict detection functions
NDB$EPOCH_TRANS() useful in circular
replication scenarios with two MySQL Clusters. Each of these
functions requires designating one cluster as primary and one as
secondary, and implements a “primary always wins”
rule for determining whether to accept conflicting changes. When
NDB$EPOCH(), conflicting rows on the
secondary are realigned with those on the primary; when using
NDB$EPOCH_TRANS(), it is transactions
containing rows in conflict (and any transactions which depend
on them) on the secondary that are realigned.
NDB$EPOCH_TRANS() as the conflict
detection function has two additional requirements:
The binary log must be written using Version 2 row events;
that is, the mysqld processes on both the
primary and the secondary must be started with
The secondary must include transaction IDs for all rows
written into its binary log. This can be done by setting
(This server option is also added in this release.)
A number of new server status variables have been added to
monitor conflict detection and resolution performed using these
See MySQL Cluster Status Variables.
For more information, see MySQL Cluster Replication Conflict Resolution.
Incompatible Change; Cluster API: Restarting a machine hosting data nodes, SQL nodes, or both, caused such nodes when restarting to time out while trying to obtain node IDs.
As part of the fix for this issue, the behavior and default
values for the NDB API
method have been improved. Due to these changes, the version
number for the included NDB client library
libndbclient.so) has been increased from
4.0.0 to 5.0.0. For NDB API applications, this means that as
part of any upgrade, you must do both of the following:
Review and possibly modify any NDB API code that uses the
method, in order to take into account its changed default
Recompile any NDB API applications using the new version of the client library.
Also in connection with this issue, the default value for each
of the two mysqld options
--ndb-wait-setup has been
increased to 30 seconds (from 0 and 15, respectively). In
addition, a hard-coded 30-second delay was removed, so that the
now handled correctly in all cases.
When replicating DML statements with
between clusters, the number of operations that failed due to
nonexistent keys was expected to be no greater than the number
of defined operations of any single type. Because the slave SQL
thread defines operations of multiple types in batches together,
code which relied on this assumption could cause
mysqld to fail.
The maximum effective value for the
configuration parameter was limited by the value of
SendBufferMemory. Now the
value set for
OverloadLimit is used
correctly, up to this parameter's stated maximum (4G).
AUTO_INCREMENT values were not set correctly
IGNORE statements affecting
NDB tables. This could lead such
statements to fail with Got error 4350 'Transaction
already aborted' from NDBCLUSTER when inserting
multiple rows containing duplicate values.
(Bug #11755237, Bug #46985)
When failure handling of an API node takes longer than 300 seconds, extra debug information is included in the resulting output. In cases where the API node's node ID was greater than 48, these extra debug messages could lead to a crash, and confuing output otherwise. This was due to an attempt to provide information specific to data nodes for API nodes as well. (Bug #62208)
In rare cases, a series of node restarts and crashes during restarts could lead to errors while reading the redo log. (Bug #62206)
Cluster Replication: A transaction that updated many (thousands of) rows executed properly on the master but failed on the slave with the error Lock wait timeout exceeded....
This issue is known to affect MySQL Cluster NDB 7.1.13 and later. (Bug #12974714)