Changes in MySQL NDB Cluster 7.5.25 (5.7.37-ndb-7.5.25) (2022-01-19, General Availability)

MySQL NDB Cluster 7.5.25 is a new release of MySQL NDB Cluster 7.5, based on MySQL Server 5.7 and including features in version 7.5 of the NDB storage engine, as well as fixing recently discovered bugs in previous NDB Cluster releases.

Obtaining MySQL NDB Cluster 7.5.  MySQL NDB Cluster 7.5 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.5, see What is New in NDB Cluster 7.5.

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)).

Bugs Fixed

• 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:

  1. Copy rows to new fragments

  2. Update distribution information (hashmap count and total fragments)

  3. Wait for scan activity using old distribution to stop

  4. Delete rows which have moved out of existing partitions

  5. Remove reference to old hashmap

  6. 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 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:

  • Row counts for virtual ndbinfo tables have been made available to the MySQL optimizer

  • Size estimates are now provided for all ndbinfo tables

  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.