macOS: A
uint64_tvalue used with%zucaused a[-Wformat]compiler warning on MacOS. (Bug #37174692)Removed a warning in
storage/ndb/src/common/util/cstrbuf.cpp. (Bug #37049014)
Microsoft Windows: Successive iterations of the sequence ndb_sign_keys
--create-keyfollowed by ndb_sign_keys--promotewere unsuccessful on Windows. (Bug #36951132)NDB Disk Data: mysqld did not use a disk scan for
NDBtables with 256 disk columns or more. (Bug #37201922)-
NDB Cluster APIs: The
Ndb_cluster_connectiondestructor callsg_eventLogger::stopAsync()in order to release the buffers used by the asynchronous logging mechanism as well as to stop the threads responsible for this logging. When theg_eventLoggerobject was deleted before theNdb_cluster_connectiondestructor was called, the application terminated after trying to use a method on a null object. This could happen in either of two ways:An API program deleted the logger object before deleting the
Ndb_cluster_connection.ndb_end()was called before theNdb_cluster_connectionwas deleted.
We solve this issue by skipping the call to
stopAsync()in theNdb_cluster_connectiondestructor wheng_eventLoggerisNULL. This fix also adds a warning to inform API users that deletingg_eventLoggerbefore calling theNdb_cluster_connectiondestructor is incorrect usage.For more information, see API Initialization and Cleanup. (Bug #37300558)
-
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) -
Work done previously to support opening
NDBtables with missing indexes was intended to allow the features of the MySQL server to be used to solve problems in cases where indexes cannot be rebuilt due to unmet constraints. With missing indexes, some of the SQL handler functionality is unavailable—for example, the use of indexes to select rows for modification efficiently, or to identify duplicates when processing modifications, or to push joins relying on indexes. This could lead to the unplanned shutdown of an NDB Cluster SQL node.In such cases, the server now simply returns an error. (Bug #37299071)
-
Recent refactoring of the transporter layer added the reporting of the presence of socket shutdown errors, but not their nature. This led to confusion in the common case where a socket shutdown is requested, but the socket is already closed by the peer. To avoid such confusion, this logging has been removed. (Bug #37243135)
References: This issue is a regression of: Bug #35750771.
-
It was not possible to create an
NDBtable with 256 or moreBLOBcolumns when also specifying a reduced inline size, as in the following SQL statement:CREATE TABLE t1 ( pk INT PRIMARY KEY, b1 BLOB COMMENT 'NDB_COLUMN=BLOB_INLINE_SIZE=100', b2 BLOB COMMENT 'NDB_COLUMN=BLOB_INLINE_SIZE=100', ..., b256 BLOB COMMENT 'NDB_COLUMN=BLOB_INLINE_SIZE=100' ) ENGINE=NDBCLUSTER;(Bug #37201818)
-
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)Improved variable names used in
start_resend(), and enhanced related debug messages to users and developers with additional information. (Bug #37157987)In certain cases, a
COPY_FRAGREQsignal did not honor a fragment scan lock. (Bug #37125935)-
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.
-
For tables using the
NDBstorage engine, the column comment optionBLOB_INLINE_SIZEwas silently ignored forTINYBLOBcolumns, and (silently) defaulted to the hard-coded 256 byte value regardless of the size provided; this was misleading to users.To fix this problem, we now specifically disallow
BLOB_INLINE_SIZEonTINYBLOBcolumns altogether, andNDBnow prints a warning saying that the column size is defaulting to 256 bytes. (Bug #36725332) -
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.
-
ndb_config did not always handle very long file paths correctly.
Our thanks to Dirkjan Bussink for the contribution. (Bug #116748, Bug #37310680)
Errors of unknown provenance were logged while assigning node IDs during cluster synchronization, leading to user doubt and concern. Logging of the data node
QMGRblock and the ndb_mgmd process relating to node ID allocation issues has therefore been improved, to supply more and better information about what is being reported in such cases. (Bug #116351, Bug #37189356)A multi-range scan sometimes lost its fragment lock for the second and subsequent ranges of the scan. (Bug #111932, Bug #35660890)