MySQL Cluster NDB 7.2.1 is a new development preview release of
MySQL Cluster, incorporating new features in the
NDB storage engine for testing and
Obtaining MySQL Cluster NDB 7.2. MySQL Cluster NDB 7.2 source code and binaries can be obtained from http://dev.mysql.com/downloads/cluster/.
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.5 through MySQL 5.5.15 (see Changes in MySQL 5.5.15 (2011-07-28)).
Added support for pushing down joins to the NDB kernel for
parallel execution across the data nodes, which can speed up
execution of joins across
tables by a factor of 20 or more in some cases. Some
restrictions apply on the types of joins that can be optimized
in this way; in particular, columns to be joined must use
exactly the same data type, and cannot be any of the
TEXT types. In addition, columns
to be joined must be part of a table index or primary key.
Support for this feature can be enabled or disabled using the
ndb_join_pushdown server system
variable (enabled by default); see the description of this
variable for more information and examples.
As part of this improvement, the status variables
Ndb_pushed_reads also been
introduced for monitoring purposes. You can also see whether a
given join is pushed down using
EXPLAIN. In addition, several new
counters relating to push-down join performance have been added
counters table in the
ndbinfo database. For more
information, see the descriptions of the status variables
The default values for a number of MySQL Cluster data node
configuration parameters have changed, to provide more
resiliency to environmental issues and better handling of some
potential failure scenarios, and to perform more reliably with
increases in memory and other resource requirements brought
about by recent improvements in join handling by
NDB. The affected parameters are
Default increased from 1500 ms to 5000 ms.
Default increased from 3000 ms to 7500 ms.
Now effectively disabled by default (default changed from
4000 ms to 0).
Default increased from 20MB to 128MB.
Default increased from 32 to 256.
In addition, when
MaxNoOfLocalScans is not
specified, the value computed for it automatically has been
increased by a factor of 4 (that is, to 4 times
times the number of data nodes in the cluster).
MySQL user privileges can now be distributed automatically
across all MySQL servers (SQL nodes) connected to the same MySQL
Cluster. Previously, each MySQL Server's user privilege
tables were required to use the
MyISAM storage engine, which meant
that a user account and its associated privileges created on one
SQL node were not available on any other SQL node without manual
intervention. MySQL Cluster now provides an SQL script file
ndb_dist_priv.sql that can be found in
share/mysql under the MySQL installation
directory; loading this script creates a stored procedure
mysql_cluster_move_privileges that can be
used following initial installation to convert the privilege
tables to the
NDB storage engine,
so that any time a MySQL user account is created, dropped, or
has its privileges updated on any SQL node, the changes take
effect immediately on all other MySQL servers attached to the
cluster. Note that you may need to execute
PRIVILEGES on any SQL nodes with connected MySQL
clients (or to disconnect and then reconnect the clients) in
order for those clients to be able to see the changes in
mysql_cluster_move_privileges has been
executed successfully, all MySQL user privileges are distributed
across all connected MySQL Servers. MySQL Servers that join the
cluster after this automatically participate in the privilege
ndb_dist_priv.sql also provides stored
routines that can be used to verify that the privilege tables
have been distributed successfully, and to perform other tasks.
For more information, see Distributed MySQL Privileges for MySQL Cluster.
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.
By default, data nodes now exhibit fail-fast behavior whenever
they encounter corrupted tuples—in other words, a data
node forcibly shuts down whenever it detects a corrupted tuple.
To override this behavior, you can disable the
data node configuration parameter, which is enabled by default.
This is a change from MySQL Cluster NDB 7.0 and MySQL Cluster
NDB 7.1, where
was disabled (so that data nodes ignored tuple corruption) by
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.
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)