This release incorporates new features in the
NDB storage engine and fixes
recently discovered bugs in MySQL Cluster NDB 7.0.5.
Obtaining MySQL Cluster NDB 7.0.5. 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.34 (see Changes in MySQL 5.1.34 (2009-04-02)).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
The ndb_config utility program can now provide an offline dump of all MySQL Cluster configuration parameters including information such as default and permitted values, brief description, and applicable section of the
config.inifile. A dump in text format is produced when running ndb_config with the new
--configinfooption, and in XML format when the options
--configinfo --xmlare used together. For more information and examples, see ndb_config — Extract MySQL Cluster Configuration Information.
Important Change; Partitioning: User-defined partitioning of an
NDBCLUSTERtable without any primary key sometimes failed, and could cause mysqld to crash.
Now, if you wish to create an
NDBCLUSTERtable with user-defined partitioning, the table must have an explicit primary key, and all columns listed in the partitioning expression must be part of the primary key. The hidden primary key used by the
NDBCLUSTERstorage engine is not sufficient for this purpose. However, if the list of columns is empty (that is, the table is defined using
PARTITION BY [LINEAR] KEY()), then no explicit primary key is required.
This change does not effect the partitioning of tables using any storage engine other than
NDBCLUSTER. (Bug #40709)
Important Note: It was not possible to perform an online upgrade from any MySQL Cluster NDB 6.x release to MySQL Cluster NDB 7.0.5 or any to earlier MySQL Cluster NDB 7.0 release.
With this fix, it is possible in MySQL Cluster NDB 7.0.6 and later to perform online upgrades from MySQL Cluster NDB 6.3.8 and later MySQL Cluster NDB 6.3 releases, or from MySQL Cluster NDB 7.0.5 or later MySQL Cluster NDB 7.0 releases. Online upgrades to MySQL Cluster NDB 7.0 releases previous to MySQL Cluster NDB 7.0.6 from earlier MySQL Cluster releases remain unsupported; online upgrades from MySQL Cluster NDB 7.0 releases previous to MySQL Cluster NDB 7.0.5 (including NDB 6.4.x beta releases) to later MySQL Cluster NDB 7.0 releases also remain unsupported. (Bug #44294)
An internal NDB API buffer was not properly initialized. (Bug #44977)
When a data node had written its GCI marker to the first page of a megabyte, and that node was later killed during restart after having processed that page (marker) but before completing a LCP, the data node could fail with file system errors. (Bug #44952)
References: See also: Bug #42564, Bug #44291.
When restarting a data nodes, management and API nodes reconnecting to it failed to re-use existing ports that had already been dynamically allocated for communications with that data node. (Bug #44866)
When ndb_config could not find the file referenced by the
--config-fileoption, it tried to read
my.cnfinstead, then failed with a misleading error message. (Bug #44846)
When a data node was down so long that its most recent local checkpoint depended on a global checkpoint that was no longer restorable, it was possible for it to be unable to use optimized node recovery when being restarted later. (Bug #44844)
References: See also: Bug #26913.
Online upgrades to MySQL Cluster NDB 7.0 from a MySQL Cluster NDB 6.3 release could fail due to changes in the handling of key lengths and unique indexes during node recovery. (Bug #44827)
--xmldid not output any entries for the
HostNameparameter. In addition, the default listed for
MaxNoOfFileswas outside the permitted range of values. (Bug #44749)
References: See also: Bug #44685, Bug #44746.
The output of ndb_config
--xmldid not provide information about all sections of the configuration file. (Bug #44685)
References: See also: Bug #44746, Bug #44749.
__builtin_expect()had the side effect that compiler warnings about misuse of
=(assignment) instead of
==in comparisons were lost when building in debug mode. This is no longer employed when configuring the build with the
--with-debugoption. (Bug #44570)
References: See also: Bug #44567.
Inspection of the code revealed that several assignment operators (
=) were used in place of comparison operators (
DbdihMain.cpp. (Bug #44567)
References: See also: Bug #44570.
When using large numbers of configuration parameters, the management server took an excessive amount of time (several minutes or more) to load these from the configuration cache when starting. This problem occurred when there were more than 32 configuration parameters specified, and became progressively worse with each additional multiple of 32 configuration parameters. (Bug #44488)
Building the MySQL Cluster NDB 7.0 tree failed when using the icc compiler. (Bug #44310)
SSL connections to SQL nodes failed on big-endian platforms. (Bug #44295)
Signals providing node state information (
CHANGE_NODE_STATE_REQ) were not propagated to all blocks of ndbmtd. This could cause the following problems:
Inconsistent redo logs when performing a graceful shutdown;
Data nodes crashing when later restarting the cluster, data nodes needing to perform node recovery during the system restart, or both.
References: See also: Bug #42564.
An NDB internal timing function did not work correctly on Windows and could cause mysqld to fail on some AMD processors, or when running inside a virtual machine. (Bug #44276)
It was possible for NDB API applications to insert corrupt data into the database, which could subquently lead to data node crashes. Now, stricter checking is enforced on input data for inserts and updates. (Bug #44132)
ndb_restore failed when trying to restore data on a big-endian machine from a backup file created on a little-endian machine. (Bug #44069)
Repeated starting and stopping of data nodes could cause ndb_mgmd to fail. This issue was observed on Solaris/SPARC. (Bug #43974)
A number of incorrectly formatted output strings in the source code caused compiler warnings. (Bug #43878)
When trying to use a data node with an older version of the management server, the data node crashed on startup. (Bug #43699)
In some cases, data node restarts during a system restart could fail due to insufficient redo log space. (Bug #43156)
NDBCLUSTERdid not build correctly on Solaris 9 platforms. (Bug #39080)
References: See also: Bug #39036, Bug #39038.
The output of ndbd
--helpdid not provide clear information about the program's
--initial-startoptions. (Bug #28905)
It was theoretically possible for the value of a nonexistent column to be read as
NULL, rather than causing an error. (Bug #27843)
Disk Data: During a checkpoint, restore points are created for both the on-disk and in-memory parts of a Disk Data table. Under certain rare conditions, the in-memory restore point could include or exclude a row that should have been in the snapshot. This would later lead to a crash during or following recovery.
This issue was somewhat more likely to be encountered when using ndbmtd. (Bug #41915)
References: See also: Bug #47832.
Disk Data: This fix supersedes and improves on an earlier fix made for this bug in MySQL 5.1.18. (Bug #24521)
Cluster Replication: A failure when setting up replication events could lead to subsequent data node failures. (Bug #44915)