MySQL NDB Cluster 7.4.34 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.
NDB Cluster could not be compiled using GCC 10 or 11. (Bug #33282549)
A buffer used in the
SUMAkernel block did not always accommodate multiple signals. (Bug #33246047)
It was possible in certain cases for an array index to exceed
NO_OF_BUCKETS. (Bug #33019959)
QMGRto check whether the node ID received from the
CM_REGREFsignal is less than
MAX_NDB_NODES. (Bug #32983311)
A check was reported missing from the code for handling
GET_TABLEID_REQsignals. To fix this issue, all code relating to all
GET_TABLEID_*signals has been removed from the
NDBsources, since these signals are no longer used or supported in NDB Cluster. (Bug #32983249)
It was possible in some cases to specify an invalid node type when working with the internal management API. Now the API specifically disallows invalid node types, and defines an “unknown” node type (
NDB_MGM_NODE_TYPE_UNKNOWN) to cover such cases. (Bug #32957364)
ndb_restore raised a warning to use
--disable-indexeswhen restoring data after the metadata had already been restored with
--disable-indexesis used to restore metadata before restoring data, the tables in the target schema have no indexes. We now check when restoring data with this option to ensure that there are no indexes on the target table, and print the warning only if the table already has indexes. (Bug #28749799)
When restoring of metadata was done using
--disable-indexes, there was no attempt to create indexes or foreign keys dependent on these indexes, but when ndb_restore was used without the option, indexes and foreign keys were created. When
--disable-indexeswas used later while restoring data,
NDBattempted to drop any indexes created in the previous step, but ignored the failure of a drop index operation due to a dependency on the index of a foreign key which had not been dropped. This led subsequently to problems while rebuilding indexes, when there was an attempt to create foreign keys which already existed.
We fix ndb_restore as follows:
--disable-indexesis used, ndb_restore now drops any foreign keys restored from the backup.
ndb_restore now checks for the existence of indexes before attempting to drop them.