MySQL Cluster NDB 7.1.13 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)).
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-nodesoption. This can be done by setting
Nodegroup = 65536in the
config.inifile for any data nodes that should be started at a later time, when first starting the cluster. (It was possible to set
NodeGroupto this value previously, but the management server failed to start.)
As part of this fix, a new data node configuration parameter
StartNoNodeGroupTimeouthas been added. When the management server sees that there are data nodes with no node group (that is, nodes for which
Nodegroup = 65536), it waits
StartNoNodeGroupTimeoutmilliseconds before treating these nodes as though they were listed with the
--nowait-nodesoption, and proceeds to start.
For more information, see Adding MySQL Cluster Data Nodes Online. (Bug #11766167, Bug #59213)
config_generationcolumn has been added to the
nodestable of the
ndbinfodatabase. 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 configuration.
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. (Bug #60946)
References: This issue is a regression of: 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.