This release incorporates new features in the
NDB storage engine and fixes
recently discovered bugs in previous MySQL Cluster NDB 7.0
Obtaining MySQL Cluster NDB 7.0. The latest MySQL Cluster NDB 7.0 binaries for supported platforms can be obtained from http://dev.mysql.com/downloads/cluster/. Source code for the latest MySQL Cluster NDB 7.0 release can be obtained from the same location. You can also access the MySQL Cluster NDB 7.0 development source tree at https://code.launchpad.net/~mysql/mysql-server/mysql-cluster-7.0.
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.51 (see Changes in MySQL 5.1.51 (2010-09-10)).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Disk Data: The
INFORMATION_SCHEMA.TABLEStable now provides disk usage as well as memory usage information for Disk Data tables. Also,
INFORMATION_SCHEMA.PARTITIONS, formerly did not show any statistics for
NDBtables. Now the
DATA_FREEcolumns contain correct information for the table's partitions.
--rewrite-databaseoption is added for ndb_restore, which makes it possible to restore to a database having a different name from that of the database in the backup.
For more information, see ndb_restore — Restore a MySQL Cluster Backup. (Bug #54327)
The NDB kernel now implements a number of statistical counters relating to actions performed by or affecting
Ndbobjects, such as starting, closing, or aborting transactions; primary key and unique key operations; table, range, and pruned scans; blocked threads waiting for various operations to complete; and data and events sent and received by
NDBCLUSTER. These NDB API counters are incremented inside the NDB kernel whenever NDB API calls are made or data is sent to or received by the data nodes. mysqld exposes these counters as system status variables; their values can be read in the output of
SHOW STATUS, or by querying the
GLOBAL_STATUStable in the
INFORMATION_SCHEMAdatabase. By comparing the values of these status variables prior to and following the execution of SQL statements that act on
NDBtables, you can observe the corresponding actions taken on the NDB API level, which can be beneficial for monitoring and performance tuning of MySQL Cluster.
Important Note: Due to an error in merging the original fix, it did not appear MySQL Cluster NDB 7.0.21; this oversight has been corrected in the current release. (Bug #58256)
This issue affects all previous MySQL Cluster NDB 7.0 releases. (Bug #60045)
--rebuild-indexescaused multi-threaded index building to occur on the master node only. (Bug #59920)
Successive queries on the
counterstable from the same SQL node returned unchanging results. To fix this issue, and to prevent similar issues from occurring in the future,
ndbinfotables are now excluded from the query cache. (Bug #59831)
CREATE TABLEstatement failed due to
NDBerror 1224 (Too many fragments), it was not possible to create the table afterward unless either it had no ordered indexes, or a
DROP TABLEstatement was issued first, even if the subsequent
CREATE TABLEwas valid and should otherwise have succeeded. (Bug #59756)
References: See also Bug #59751.
When attempting to create a table on a MySQL Cluster with many standby data nodes (setting
config.inifor the nodes that should wait, starting the nodes that should start immediately with the
--nowait-nodesoption, and using the
MAX_ROWSoption), mysqld miscalculated the number of fragments to use. This caused the
CREATE TABLEto fail.Note
CREATE TABLEfailure caused by this issue in turn prevented any further attempts to create the table, even if the table structure was simplified or changed in such a way that the attempt should have succeeded. This “ghosting” issue is handled in Bug #59756.
NDBsometimes treated a simple (not unique) ordered index as unique. (Bug #59519)
The logic used in determining whether to collapse a range to a simple equality was faulty. In certain cases, this could cause
NDBto treat a range as if it were a primary key lookup when determining the query plan to be used. Although this did not affect the actual result returned by the query, it could in such cases result in inefficient execution of queries due to the use of an inappropriate query plan. (Bug #59517)
When a query used multiple references to or instances of the same physical tables,
NDBfailed to recognize these multiple instances as different tables; in such a case,
NDBcould incorrectly use condition pushdown on a condition referring to these other instances to be pushed to the data nodes, even though the condition should have been rejected as unpushable, leading to invalid results. (Bug #58791)
Cluster API: When calling
NdbEventOperation::execute()during a node restart, it was possible to get a spurious error 711 (System busy with node restart, schema operations not allowed when a node is starting). (Bug #59723)
Cluster API: When an NDBAPI client application was waiting for more scan results after calling
NdbScanOperation::nextResult(), the calling thread sometimes woke up even if no new batches for any fragment had arrived, which was unnecessary, and which could have a negative impact on the application's performance. (Bug #52298)
The “greedy” query plan optimizer failed to consider the size of intermediate query results when calculating the cost of a query. This could result in slowly executing queries when there are much faster execution plans available. (Bug #59326, Bug #11766256)
OUTER JOINquery using
WHEREcould return an incorrect result. (Bug #58490, Bug #11765513)
For a query that used a subquery that included
GROUP BYinside a
< ANY()construct, no rows were returned when there should have been. (Bug #56690, Bug #11763918)