Important Change: The deprecated data node option --connect-delay has been removed. This option was a synonym for --connect-retry-delay, which was not honored in all cases; this issue has been fixed, and the option now works correctly. In addition, the short form -r for this option has been deprecated, and you should expect it to be removed in a future release. (Bug #31565810)

References: See also: Bug #33362935.

NDB Cluster APIs: It is no longer possible to use the DIVERIFYREQ signal asynchronously. (Bug #33161562)

Timing of wait for scans log output during online reorganization was not performed correctly. As part of this fix, we change timing to generate one message every 10 seconds rather than scaling indefinitely, so as to supply regular updates. (Bug #35523977)

Added missing values checks in ndbd and ndbmtd. (Bug #33661024)

Online table reorganization increases the number of fragments of a table, and moves rows between them. This is done in the following steps:

Due to a counting error, it was possible for the reorganization to hang in step 6; the scan reference count was not decremented, and thus never reached zero as expected. (Bug #33523991)

The same pushed join on NDB tables returned an incorrect result when the batched_key_access optimizer switch was enabled.

This issue arose as follows: When the batch key access (BKA) algorithm is used to join two tables, a set of batched keys is first collected from one of the tables; a multirange read (MRR) operation is constructed against the other. A set of bounds (ranges) is specified on the MRR, using the batched keys to construct each bound.

When result rows are returned it is necessary to identify which range each returned row comes from. This is used to identify the outer table row to perform the BKA join with. When the MRR operation in question was a root of a pushed join operation, SPJ was unable to retrieve this identifier (RANGE_NO). We fix this by implementing the missing SPJ API functionality for returning such a RANGE_NO from a pushed join query. (Bug #33416308)

The MySQL Optimizer uses two different methods, handler::read_cost() and Cost_model::page_read_cost(), to estimate the cost for different access methods, but the cost values returned by these were not always comparable; in some cases this led to the wrong index being chosen and longer execution time for effected queries. To fix this for NDB, we override the optimizer's page_read_cost() method with one specific to NDBCLUSTER. It was also found while working on this issue that the NDB handler did not implement the read_time() method, used by read_cost(); this method is now implemented by ha_ndbcluster, and thus the optimizer can now properly take into account the cost difference for NDB when using a unique key as opposed to an ordered index (range scan). (Bug #33317872)

In certain cases, an event's category was not properly detected. (Bug #33304814)

DBDICT did not always perform table name checks correctly. (Bug #33161548)

Added a number of missing ID and other values checks in ndbd and ndbmtd. (Bug #33161486, Bug #33162047)

SET_LOGLEVELORD signals were not always handled correctly. (Bug #33161246)

DUMP 11001 did not always handle all of its arguments correctly. (Bug #33157513)

File names were not always verified correctly. (Bug #33157475)

Added a number of missing ID and other values checks in ndbd and ndbmtd. (Bug #32983700, Bug #32893708, Bug #32957478, Bug #32983256, Bug #32983339, Bug #32983489, Bug #32983517, Bug #33157527, Bug #33157531, Bug #33161271, Bug #33161298, Bug #33161314, Bug #33161331, Bug #33161372, Bug #33161462, Bug #33161511, Bug #33161519, Bug #33161537, Bug #33161570, Bug #33162059, Bug #33162065, Bug #33162074, Bug #33162082, Bug #33162092, Bug #33162098, Bug #33304819)

The management server did not always handle events of the wrong size correctly. (Bug #32957547)

In some cases, issues with the redo log while restoring a backup led to an unplanned shutdown of the data node. To fix this, when the redo log file is not available for writes, we now include the correct wait code and waiting log part in the CONTINUEB signal before sending it. (Bug #32733659)

References: See also: Bug #31585833.

A query used by MySQL Enterprise Monitor to monitor memory use in NDB Cluster became markedly less performant as the number of NDB tables increased. We fix this as follows:

Following these improvements, queries against ndbinfo tables should be noticeably faster. (Bug #28658625)

NDB did not close any pending schema transactions when returning an error from internal system table creation and drop functions.