MySQL NDB Cluster 7.5.11 is a new release of MySQL NDB Cluster
7.5, based on MySQL Server 5.7 and including features in version
7.5 of the
NDB storage engine, as
well as fixing recently discovered bugs in previous NDB Cluster
Obtaining MySQL NDB Cluster 7.5. MySQL NDB Cluster 7.5 source code and binaries can be obtained from https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in MySQL NDB Cluster 7.5, see What is New in NDB Cluster 7.5.
This release also incorporates all bug fixes and changes made in previous NDB Cluster releases, as well as all bug fixes and feature changes which were added in mainline MySQL 5.7 through MySQL 5.7.23 (see Changes in MySQL 5.7.23 (2018-07-27, General Availability)).
ndbinfo Information Database: It was possible following a restart for (sometimes incomplete) fallback data to be used in populating the
ndbinfo.processestable, which could lead to rows in this table with empty
process_namevalues. Such fallback data is no longer used for this purpose. (Bug #27985339)
MySQL NDB ClusterJ: ClusterJ could not be built from source using JDK 9. (Bug #27977985)
An internal buffer being reused immediately after it had been freed could lead to an unplanned data node shutdown. (Bug #27622643)
References: See also: Bug #28698831.
NDBonline backup consists of data, which is fuzzy, and a redo and undo log. To restore to a consistent state it is necessary to ensure that the log contains all of the changes spanning the capture of the fuzzy data portion and beyond to a consistent snapshot point. This is achieved by waiting for a GCI boundary to be passed after the capture of data is complete, but before stopping change logging and recording the stop GCI in the backup's metadata.
At restore time, the log is replayed up to the stop GCI, restoring the system to the state it had at the consistent stop GCI. A problem arose when, under load, it was possible to select a GCI boundary which occurred too early and did not span all the data captured. This could lead to inconsistencies when restoring the backup; these could be be noticed as broken constraints or corrupted
Now the stop GCI is chosen is so that it spans the entire duration of the fuzzy data capture process, so that the backup log always contains all data within a given stop GCI. (Bug #27497461)
References: See also: Bug #27566346.
NDBtables, when a foreign key was added or dropped as a part of a DDL statement, the foreign key metatdata for all parent tables referenced should be reloaded in the handler on all SQL nodes connected to the cluster, but this was done only on the mysqld on which the statement was executed. Due to this, any subsequent queries relying on foreign key metadata from the corresponding parent tables could return inconsistent results. (Bug #27439587)
References: See also: Bug #82989, Bug #24666177.
The internal function
BitmaskImpl::setRange()set one bit fewer than specified. (Bug #90648, Bug #27931995)
It was not possible to create an
FOR_RA_BY_LDM_X_4. (Bug #89811, Bug #27602352)
References: This issue is a regression of: Bug #81759, Bug #23544301.
When the internal function
ha_ndbcluster::copy_fk_for_offline_alter()checked dependent objects on a table from which it was supposed to drop a foreign key, it did not perform any filtering for foreign keys, making it possible for it to attempt retrieval of an index or trigger instead, leading to a spurious Error 723 (No such table).
During the execution of
CREATE TABLE ... IF NOT EXISTS, the internal
open_table()finds out that the requested table already exists. In certain cases,
get_default_num_partitions()was called without the associated
thd_ndbobject being initialized, leading to failure of the statement with MySQL error 157 Could not connect to storage engine. Now
get_default_num_partitions()always checks for the existence of this
thd_ndbobject, and initializes it if necessary.