MySQL NDB Cluster 7.4.21 is a new release of MySQL NDB Cluster
7.4, based on MySQL Server 5.6 and including features in version
7.4 of the
NDB storage engine, as
well as fixing recently discovered bugs in previous NDB Cluster
Obtaining MySQL NDB Cluster 7.4. MySQL NDB Cluster 7.4 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.4, see What is New in NDB Cluster 7.4.
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.6 through MySQL 5.6.41 (see Changes in MySQL 5.6.41 (2018-07-27, General Availability)).
NDB Cluster APIs: When
Ndb::dropEventOperation()tried to clean up a pending event, it failed to clear a pointer to the list of GCI operations being deleted and discarded (
Gci_opsobject), so that this pointer referred to a deleted object. GCI operations arriving after this could then be inserted as part of the next such list belonging to the now-deleted object, leading to memory corruption and other issues. (Bug #90011, Bug #27675005)
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.