This release incorporates new features in the
NDB storage engine and fixes
recently discovered bugs in MySQL Cluster NDB 7.0.12.
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.41 (see Changes in MySQL 5.1.41 (2009-11-05)).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
A new configuration parameter
HeartbeatThreadPrioritymakes it possible to select between a first-in, first-out or round-round scheduling policy for management node and API node heartbeat threads, as well as to set the priority of these threads. See Defining a MySQL Cluster Management Server, or Defining SQL and Other API Nodes in a MySQL Cluster, for more information. (Bug #49617)
Start phases are now written to the data node logs. (Bug #49158)
Disk Data: The ndb_desc utility can now show the extent space and free extent space for subordinate
TEXTcolumns (stored in hidden
BLOBtables by NDB). A
--blob-infooption has been added for this program that causes ndb_desc to generate a report for each subordinate BLOB table. For more information, see ndb_desc — Describe NDB Tables. (Bug #50599)
When performing a system restart of a MySQL Cluster where multi-threaded data nodes were in use, there was a slight risk that the restart would hang due to incorrect serialization of signals passed between LQH instances and proxies; some signals were sent using a proxy, and others directly, which meant that the order in which they were sent and received could not be guaranteed. If signals arrived in the wrong order, this could cause one or more data nodes to hang. Now all signals that need to be sent and received in the same order are sent using the same path. (Bug #51645)
When one or more data nodes read their LCPs and applied undo logs significantly faster than others, this could lead to a race condition causing system restarts of data nodes to hang. This could most often occur when using both ndbd and ndbmtd processes for the data nodes. (Bug #51644)
When deciding how to divide the REDO log, the
DBDIHkernel block saved more than was needed to restore the previous local checkpoint, which could cause REDO log space to be exhausted prematurely (
NDBerror 410). (Bug #51547)
DML operations can fail with
NDBerror 1220 (REDO log files overloaded...) if the opening and closing of REDO log files takes too much time. If this occurred as a GCI marker was being written in the REDO log while REDO log file 0 was being opened or closed, the error could persist until a GCP stop was encountered. This issue could be triggered when there was insufficient REDO log space (for example, with configuration parameter settings
NoOfFragmentLogFiles = 6and
FragmentLogFileSize = 6M) with a load including a very high number of updates. (Bug #51512)
References: See also Bug #20904.
A side effect of the ndb_restore
--rebuild-indexesoptions is to change the schema versions of indexes. When a mysqld later tried to drop a table that had been restored from backup using one or both of these options, the server failed to detect these changed indexes. This caused the table to be dropped, but the indexes to be left behind, leading to problems with subsequent backup and restore operations. (Bug #51374)
ndb_restore crashed while trying to restore a corrupted backup, due to missing error handling. (Bug #51223)
The ndb_restore message
Successfully created index `PRIMARY`...was directed to
stdout. (Bug #51037)
NoOfReplicasequal to 1 or 2, if data nodes from one node group were restarted 256 times and applications were running traffic such that it would encounter
NDBerror 1204 (Temporary failure, distribution changed), the live node in the node group would crash, causing the cluster to crash as well. The crash occurred only when the error was encountered on the 256th restart; having the error on any previous or subsequent restart did not cause any problems. (Bug #50930)
Replication of a MySQL Cluster using multi-threaded data nodes could fail with forced shutdown of some data nodes due to the fact that ndbmtd exhausted
LongMessageBuffermuch more quickly than ndbd. After this fix, passing of replication data between the
SUMANDB kernel blocks is done using
Until you can upgrade, you may be able to work around this issue by increasing the
LongMessageBuffersetting; doubling the default should be sufficient in most cases. (Bug #46914)
Disk Data: For a Disk Data tablespace whose extent size was not equal to a whole multiple of 32K, the value of the
FREE_EXTENTScolumn in the
INFORMATION_SCHEMA.FILEStable was smaller than the value of
As part of this fix, the implicit rounding of
NDBCLUSTER(see CREATE TABLESPACE Syntax) is now done explicitly, and the rounded values are used for calculating
INFORMATION_SCHEMA.FILEScolumn values and other purposes. (Bug #49709)
References: See also Bug #31712.
Disk Data: Once all data files associated with a given tablespace had been dropped, there was no way for MySQL client applications (including the mysql client) to tell that the tablespace still existed. To remedy this problem,
INFORMATION_SCHEMA.FILESnow holds an additional row for each tablespace. (Previously, only the data files in each tablespace were shown.) This row shows
FILE_NAMEcolumn. (Bug #31782)
Disk Data: It was possible to issue a
ALTER TABLESPACEstatement in which
INITIAL_SIZEwas less than
EXTENT_SIZE. (In such cases,
INFORMATION_SCHEMA.FILESerroneously reported the value of the
1and that of the
0.) Now when either of these statements is issued such that
INITIAL_SIZEis less than
EXTENT_SIZE, the statement fails with an appropriate error message. (Bug #31712)
References: See also Bug #49709.
Cluster API: An issue internal to ndb_mgm could cause problems when trying to start a large number of data nodes at the same time. (Bug #51273)
References: See also Bug #51310.