MySQL Cluster NDB 7.1.14 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)).
Ndb_getinaddr()function has been rewritten to use
my_gethostbyname_r()(which is removed in a later version of the MySQL Server). (Bug #12542120)
mysql_upgrade failed when performing an online upgrade from MySQL Cluster NDB 7.1.8 or an earlier release to MySQL Cluster NDB 7.1.9 or later in which the SQL nodes were upgraded before the data nodes. This issue could occur during any online upgrade or downgrade where one or more
ndbinfotables had more, fewer, or differing columns between the two versions, and when the data nodes were not upgraded before the SQL nodes.
For more information, see Upgrade and downgrade compatibility: MySQL Cluster NDB 7.x. (Bug #11885602, Bug #12581895, Bug #12581954)
Two unused test files in
storage/ndb/test/sqlcontained incorrect versions of the GNU Lesser General Public License. The files and the directory containing them have been removed. (Bug #11810156)
References: See also: Bug #11810224.
Error 1302 gave the wrong error message (Out of backup record). This has been corrected to A backup is already running. (Bug #11793592)
When using two management servers, issuing in an ndb_mgm client connected to one management server a
STOPcommand for stopping the other management server caused Error 2002 (Stop failed ... Send to process or receive failed.: Permanent error: Application error), even though the
STOPcommand actually succeeded, and the second ndb_mgmd was shut down. (Bug #61147)
In ndbmtd, a node connection event is detected by a
CMVMIthread which sends a
CONNECT_REPsignal to the
QMGRkernel block. In a few isolated circumstances, a signal might be transferred to
QMGRdirectly by the
NDBtransporter before the
CONNECT_REPsignal actually arrived. This resulted in reports in the error log with status
Temporary error, restart node, and the message Internal program error. (Bug #61025)
Under heavy loads with many concurrent inserts, temporary failures in transactions could occur (and were misreported as being due to
NDBError 899 Rowid already allocated). As part of the fix for this issue,
NDBError 899 has been reclassified as an internal error, rather than as a temporary transaction error. (Bug #56051, Bug #11763354)
Disk Data: Accounting for
MaxNoOfOpenFileswas incorrect with regard to data files in MySQL Cluster Disk Data tablespaces. This could lead to a crash when
MaxNoOfOpenFileswas exceeded. (Bug #12581213)
Cluster Replication: Operations that updated unique keys of
NDBtables could cause duplicate key errors when trying to execute the binary log. (Previously, row events in the binary log were ordered according to the partitioning of the base table, which could differ in order within the epoch for that in which they were executed.
To keep this from happening, unique keys are now updated in deferred mode, meaning that all table rows are updated before any unique indexes are checked. Thus, the order of the row updates is no longer important.
You should be aware that deferring constraint checking in this way is currently supported only by
NDB, and thus only for replication between NDB tables on both the master and the slave. You cannot replicate updates of unique keys successfully when replicating from
NDBto a different storage engine such as
InnoDB. (Bug #47952, Bug #11756082)