This is the first MySQL Cluster NDB 6.1 release, incorporating
new features and bugfixes made for the
NDB storage engine made since
branching from MySQL 5.1.14 standard (see
Changes in MySQL 5.1.14 (2006-12-05)).
MySQL Cluster NDB 6.1 no longer in development. MySQL Cluster NDB 6.1 (formerly known as “MySQL Cluster Carrier Grade Edition 6.1.x”) is no longer being developed or maintained; if you are using a MySQL Cluster NDB 6.1 release, you should upgrade to the latest version of MySQL Cluster, which is available from http://dev.mysql.com/downloads/cluster/ .
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
A new configuration parameter
enables additional control of data node memory usage.
Previously, only warnings at predetermined percentages of memory
allocation were given; setting this parameter enables that
behavior to be overridden.
When a data node was shut down using the management client
STOP command, a connection event
NDB_LE_Connected) was logged instead of a
disconnection event (
MEDIUMTEXT columns of Disk Data
tables were stored in memory rather than on disk, even if the
columns were not indexed.
Disk Data: When restoring from backup a cluster containing any Disk Data tables with hidden primary keys, a node failure resulted which could lead to a crash of the cluster. (Bug #24166)
Extents that should have been available for re-use following a
DROP TABLE operation were not
actually made available again until after the cluster had
performed a local checkpoint.
TRUNCATE TABLE in various
combinations with system restarts between these operations could
lead to the eventual failure of a system restart.
Disk Data: Performing a node restart with a newly dropped Disk Data table could lead to failure of the node during the restart. (Bug #24917)
Cluster API: A unique index lookup on a nonexistent tuple could lead to a data node timeout (error 4012). (Bug #25059)
method using execution type
Commit and abort
AO_IgnoreError could lead to a crash
of the transaction coordinator (
When using the
method, a very long timeout (greater than 5 minutes) could
result if the last data node being polled was disconnected from
Cluster API: Due to an error in the computation of table fragment arrays, some transactions were not executed from the correct starting point. (Bug #24914)
Under certain rare circumstances, local checkpoints were not performed properly, leading to an inability to restart one or more data nodes. (Bug #24664)