MySQL NDB Cluster 7.6.33 is a new release of NDB 7.6, based on
MySQL Server 5.7 and including features in version 7.6 of the
NDB storage engine, as well as fixing
recently discovered bugs in previous NDB Cluster releases.
Obtaining NDB Cluster 7.6. NDB Cluster 7.6 source code and binaries can be obtained from https://dev.mysql.com/downloads/cluster/.
For an overview of changes made in NDB Cluster 7.6, see What is New in NDB Cluster 7.6.
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.44 (see Changes in MySQL 5.7.44 (2023-10-25, General Availability)).
Added
CONTRIBUTING.mdandSECURITY.mdfiles to the MySQL sources to conform to Oracle's Open Source guidelines. (Bug #36998165)
-
InnoDB: An assertion failure was raised when creating a
FULLTEXTindex on a table with anFTS_DOC_IDvalue greater than 4294967295. (Bug #36879147)References: See also: Bug #37387224.
-
NDB Cluster APIs: Removed known causes of API node versus data node state misalignments, and improved the handling of state misalignments when detected. In one such case, separate handling of scan errors in the
NDBkernel and those originating in API programs led to cleanup not being performed after some scans. Handling ofDBTCand API state alignment errors has been improved by this set of fixes, as well as scan protocol timeout handling inDBSPJ; now, when such misalignments in state are detected, the involved API nodes are disconnected rather than the data node detecting it being forced to shut down. (Bug #20430083, Bug #22782511, Bug #23528433, Bug #28505289, Bug #36273474, Bug #36395384, Bug #36838756, Bug #37022773, Bug #37022901, Bug #37023549)References: See also: Bug #22782511, Bug #23528433, Bug #36273474, Bug #36395384, Bug #36838756.
-
ndbinfo Information Database: At table create and drop time, access of
ndbinfotables such asoperations_per_fragmentandmemory_per_fragmentsometimes examined data which was not valid.To fix this, during scans of these
ndbinfotables, we ignore any fragments from tables in transient states at such times due to being created or dropped. (Bug #37140331) -
In some cases, the occurrence of node failures during shutdown led to the cluster becoming unrecoverable without manual intervention.
We fix this by modifying global checkpoint ID (GCI) information propagation (
CopyGCImechanism) to reject propagation of any set of GCI information which does not describe the ability to recover the cluster automatically as part of a system restart. (Bug #37163647)References: See also: Bug #37162636.
In some cases, node failures during an otherwise graceful shutdown could lead to a cluster becoming unrecoverable without manual intervention. This fix modifies the generic GCI info propagation mechanism (
CopyGCI) to reject propagating any set of GCI information which does not describe the ability to recover a cluster automatically. (Bug #37162636)-
AppArmor denied access to
/proc/$pid/task/$thread_id/mem, a file required to generate a stack trace. (Bug #37063288)References: See also: Bug #37387034.
-
In cases where
NDBexperienced an API protocol timeout when attempting to close a scan operation, it considered theDBTCApiConnectRecordinvolved to be lost for further use, at least until the API disconnected and API failure handling withinDBTCreclaimed the record.This has been improved by having the API send a
TCRELEASEREQsignal toDBTCin such cases, performing API failure handling for a singleApiConnectRecordwithinDBTC. (Bug #37023661)References: See also: Bug #36273474, Bug #36395384, Bug #37022773, Bug #37022901, Bug #37023549.
-
Improved the internal function
my_print_help(). (Bug #36615714)References: See also: Bug #37387224.
-
A subquery containing an aggregate function
WITH ROLLUPwhich was part of a row value comparator was not always processed correctly. (Bug #36593235)References: See also: Bug #37387180. This issue is a regression of: Bug #30969045, Bug #30921780, Bug #26227613, Bug #29134467, Bug #30967158.
-
Testing revealed that a fix for a previous issue which added a check of the
ApiConnectRecordfailure number against the system's current failure number did not initialize theApiConnectRecordfailure number in all cases. (Bug #36155195)References: This issue is a regression of: Bug #36028828.