MySQL NDB Cluster 7.6.21 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.37 (see Changes in MySQL 5.7.37 (2022-01-18, General Availability)).
Important Change: The deprecated data node option
--connect-delayhas 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
-rfor 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
DIVERIFYREQsignal asynchronously. (Bug #33161562)
wait for scanslog 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)
Online table reorganization increases the number of fragments of a table, and moves rows between them. This is done in the following steps:
Copy rows to new fragments
Update distribution information (hashmap count and total fragments)
Wait for scan activity using old distribution to stop
Delete rows which have moved out of existing partitions
Remove reference to old hashmap
Wait for scan activity started since step 2 to stop
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
NDBtables returned an incorrect result when the
batched_key_accessoptimizer 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,
SPJwas unable to retrieve this identifier (
RANGE_NO). We fix this by implementing the missing
SPJAPI functionality for returning such a
RANGE_NOfrom a pushed join query. (Bug #33416308)
The MySQL Optimizer uses two different methods,
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
NDBhandler 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
NDBwhen 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)
DBDICTdid not always perform table name checks correctly. (Bug #33161548)
SET_LOGLEVELORDsignals were not always handled correctly. (Bug #33161246)
DUMP 11001did 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)
The order of parameters used in the argument to ndb_import
--csvoptis now handled consistently, with the rightmost parameter always taking precedence. This also applies to duplicate instances of a parameter. (Bug #32822757)
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
CONTINUEBsignal before sending it. (Bug #32733659)
References: See also: Bug #31585833.
When a local data manager had no fragments, the data node could not be restarted. While it is unusual, this lack of any fragments can occur when there have been changes in the number of LDMs since any tables were last created. (Bug #32288569)
A query used by MySQL Enterprise Monitor to monitor memory use in NDB Cluster became markedly less performant as the number of
NDBtables increased. We fix this as follows:
Row counts for virtual
ndbinfotables have been made available to the MySQL optimizer
Size estimates are now provided for all
Following these improvements, queries against
ndbinfotables should be noticeably faster. (Bug #28658625)
NDBdid not close any pending schema transactions when returning an error from internal system table creation and drop functions.