MySQL NDB Cluster 7.5.13 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.25 (see Changes in MySQL 5.7.25 (2019-01-21, General Availability)).
Important Change: When restoring to a cluster using data node IDs different from those in the original cluster, ndb_restore tried to open files corresponding to node ID 0. To keep this from happening, the
--backupidoptions—neither of which has a default value—are both now explicitly required when invoking ndb_restore. (Bug #28813708)
Packaging; MySQL NDB ClusterJ:
libndbclientwas missing from builds on some platforms. (Bug #28997603)
NDB Disk Data: When a log file group had more than 18 undo logs, it was not possible to restart the cluster. (Bug #251155785)
References: See also: Bug #28922609.
NDB Replication: When writes on the master—done in such a way that multiple changes affecting
BLOBcolumn values belonging to the same primary key were part of the same epoch—were replicated to the slave, Error 1022 occurred due to constraint violations in the
NDB$BLOB_table. (Bug #28746560)
When only the management server but no data nodes were started,
RESTART ALLtimed out and eventually failed. This was because, as part of a restart, ndb_mgmd starts a timer, sends a
STOP_REQsignal to all the data nodes, and waits for all of them to reach node state
SL_CMVMI. The issue arose becaue no
STOP_REQsignals were ever sent, and thus no data nodes reached
SL_CMVMI. This meant that the timer always expired, causing the restart to fail. (Bug #28728485, Bug #28698831)
References: See also: Bug #11757421.
ANALYZE TABLEon an
NDBtable with an index having longer than the supported maximum length caused data nodes to fail. (Bug #28714864)
It was possible in certain cases for nodes to hang during an initial restart. (Bug #28698831)
References: See also: Bug #27622643.
The output of ndb_config
--query-allnow shows that configuration changes for the
MaxNoOfExecutionThreadsdata node parameters require system initial restarts (
restart="system" initial="true"). (Bug #28494286)
When tables with
BLOBcolumns were dropped and then re-created with a different number of
BLOBcolumns the event definitions for monitoring table changes could become inconsistent in certain error situations involving communication errors when the expected cleanup of the corresponding events was not performed. In particular, when the new versions of the tables had more
BLOBcolumns than the original tables, some events could be missing. (Bug #27072756)
When running a cluster with 4 or more data nodes under very high loads, data nodes could sometimes fail with Error 899 Rowid already allocated. (Bug #25960230)
When starting, a data node copies metadata, while a local checkpoint updates metadata. To avoid any conflict, any ongoing LCP activity is paused while metadata is being copied. An issue arose when a local checkpoint was paused on a given node, and another node that was also restarting checked for a complete LCP on this node; the check actually caused the LCP to be completed before copying of metadata was complete and so ended the pause prematurely. Now in such cases, the LCP completion check waits to complete a paused LCP until copying of metadata is finished and the pause ends as expected, within the LCP in which it began. (Bug #24827685)
Asynchronous disconnection of mysqld from the cluster caused any subsequent attempt to start an NDB API transaction to fail. If this occurred during a bulk delete operation, the SQL layer called
HA::end_bulk_delete(), whose implementation by
ha_ndbclusterassumed that a transaction had been started, and could fail if this was not the case. This problem is fixed by checking that the transaction pointer used by this method is set before referencing it. (Bug #20116393)
NdbScanFilterdid not always handle
NULLaccording to the SQL standard, which could result in sending non-qualifying rows to be filtered (otherwise not necessary) by the MySQL server. (Bug #92407, Bug #28643463)
References: See also: Bug #93977, Bug #29231709.
NDBattempted to use condition pushdown on greater-than (
>) and less-than (
<) comparisons with
ENUMcolumn values but this could cause rows to be omitted in the result. Now such comparisons are no longer pushed down. Comparisons for equality (
=) and inequality (
ENUMvalues are not affected by this change, and conditions including these comparisons can still be pushed down. (Bug #92321, Bug #28610217)