Changes in MySQL NDB Cluster 9.7.4 (2026-10-22)

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

Obtaining MySQL NDB Cluster 9.7.  NDB Cluster 9.7 source code and binaries can be obtained from https://dev.mysql.com/downloads/cluster/.

For an overview of major changes made in NDB Cluster 9.7, see What is New in MySQL NDB Cluster 9.7.

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 9 through MySQL 9.7.4 (see Changes in MySQL NDB Cluster 9.7.4 (2026-10-22)).

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• ndb_restore now supports --log-parallelism=N to control concurrent backup log-event application independently of --parallelism, which continues to control DATA row application. The default value, 0, inherits --parallelism; valid values range from 0 through the number of backup parts multiplied by 1024 and may be higher or lower than --parallelism. Operations on the same row remain serialized. Temporary LOG restore errors now use retry accounting and geometric backoff aligned with DATA restore. (Bug #39930283)

• The ndbinfo.transporter_activity activity histograms now use fixed boundaries ranging from 100 milliseconds through 80 seconds instead of boundaries derived from each link's heartbeat interval. This keeps histogram boundaries consistent across links with different heartbeat settings and permits meaningful histograms without heartbeating. (Bug #39538065)

• HeartbeatIntervalDbApi can now be overridden in individual API-node configuration sections, allowing ndbmysql and application SQL nodes to use different heartbeat intervals. Nodes without an override retain the global DB/default value. Data nodes track the effective interval for each API node and use it for ndbinfo reporting and late-heartbeat detection while remaining compatible with older API_REGREQ signals. (Bug #38703055)

Bugs Fixed

• During an NDB redo-log file change, a metadata-page write could incorrectly mark a buffered GCI completion record as flushed. If subsequent redo activity stopped, the record could remain buffered, preventing the GCP save protocol from advancing. (Bug #39966600)

• NDB data nodes consumed approximately 4100 unnecessary bytes for every LQH fragment record because a debug-only lock array remained present in runtime builds. The array is no longer included, reducing data-node memory consumption. (Bug #39899970)

• Fixed an issue relating to NDB management-server logging controls. (Bug #39832141)

• ndb_restore could remain running indefinitely after a permanent error or exhausted retries while concurrently applying backup log records, without a success or failure result. Restore threads now signal failure, allowing the process to exit promptly. Errors were returned similar to the following:

  Redo log part ... problem started : Low space
  Redo log part ... problem started : Next file not open on time
  Gci record write is waiting for the redo log file to be changed

  (Bug #39672125)

• ndb_restore could abort when restoring an old-format compressed NDB backup containing at least 4 GB of uncompressed data because the truncated size in the AZ31 header did not match the full decompressed byte count. The consistency check now compares the low 32 bits for these files. Errors were returned similar to the following:

  2026-06-25 16:32:13 Warning: All data was not read, can not check file consistency. 
  Data read 12616794112 of 4026859520 bytes.
  storage/ndb/tools/restore/Restore.cpp:1430: require((!m_xfile.is_open())) failed
  Aborted

  The ndbxfrm utility also adds the --keep-file option and a warning for size-check inconsistencies. (Bug #39658762)

• On multithreaded ndbmtd configurations where DIH and TC or SPJ ran on different threads, node failure could cause new work to be sent to the failed node before it was marked unavailable. This could result in unanswered signals, timeouts, lingering transaction state, or assertion failures. Node-failure processing now completes the local availability updates before notifying upper-layer blocks. (Bug #39574448)

• Large transactions that repeatedly updated the same row, particularly when ordered indexes were present, could require enough commit or rollback cleanup to exceed the watchdog threshold and restart a data node. The new MaxRowVersionsPerTransaction data-node parameter limits the number of versions of one row that a transaction may prepare. The default value is 1000, and the valid range is 3 through 16383. Changing MaxRowVersionsPerTransaction requires a data-node restart.

  Reaching the limit returns NDB error 927 before the watchdog-prone cleanup path:

  NDB error 927: Too many row versions in one transaction (increase MaxRowVersionsPerTransaction)

  (Bug #39559817)

• During NDB upgrades, restarting SQL pods could intermittently fail to obtain an NDB node ID, causing repeated pod restarts or mysqld shutdown. The temporary node-ID allocation condition is now retried instead of being treated as a permanent failure. Errors were returned similar to the following:

  [ERROR] [MY-010865] [NDB] Failed to initialize connection(s)
  [ERROR] [MY-010865] [NDB] Failed to initialize ndbcluster, aborting!

  (Bug #37355499)

• During a rolling restart or data-node failure, transaction coordinator takeover could crash the master data node while rolling forward a transaction from an older global checkpoint after a newer checkpoint had opened. Errors were returned similar to the following:

  Error: 2341
  Error data: Can not find global checkpoint record for commit.

  Takeover can now reopen the missing older checkpoint record and recover the transaction without crashing the master data node. (Bug #36907359)