MySQL NDB Cluster 9.x continues to focus on the qualities that matter most in production: clear operational insight, predictable behaviour under failure, efficient application access, and faster recovery. This release series adds practical observability across the cluster, strengthens several exceptional paths, and expands the control available to users.
Better visibility into cluster operation
Diagnosing a distributed system depends on having the right context in the right log. NDB Cluster now reports node-log timestamps with microsecond precision, making closely spaced activity easier to correlate across data nodes and applications.
Transporter disconnect messages identify the source node, while Global Schema Lock messages identify the responsible NDB component or user session and include information about the Performance Schema thread so that it can be traced.
When a node drops out or a connection is lost, the most useful evidence is often on the data node itself. NDB Cluster now logs more of these events locally—including joins, leaves, API disconnects, startup, and restart activity—so that information is still available even in cases when a connection problem also affects log of events to the management node log. The messages also include node-group details, helping users quickly see which node-group a node belongs to.
Heartbeat diagnostics become more useful before a node is declared dead. NDB Cluster adds finer-grained transporter activity and heartbeat information through `ndbinfo` – the NDB Cluster information Database – along with late heartbeat reporting, so users can identify growing communication delays and tune configurations before they become availability events.
Redo log pressure is easier to understand as well. NDB cluster now reports the start and resolution of important redo log problem states, including buffer exhaustion, space exhaustion, file-change problems, and redo I/O overload. These messages help distinguish queued application work — which provides backpressure — from operations that must be aborted, and provide clearer evidence for capacity and I/O tuning.
Stronger handling of failures and timeouts
Several improvements strengthen the paths NDB Cluster takes when a client, data node, or protocol exchange does not behave as expected. API node failure handling now exposes more detail about Transaction Coordinator cleanup, including the work needed to resolve transactions and commit-ack markers. It also bounds prolonged failure handling so a cluster is not left indefinitely waiting for a state that requires escalation.
Data node watchdog shutdown handling is more robust, reducing the risk of watchdog activity obscuring an orderly shutdown. Additional defensive checks improve reference count management while the transaction coordinator processes API failures.
NDBAPI now handles timeouts more consistently across table, ordered-index, and SPJ scans. It can better distinguish errors raised by the API from those originating in the kernel, and it cleans up properly if closing a timed-out scan also times out.
At the storage layer, NDB now has an improved resilience for partial filesystem writes. Previously, when a write completed only partially — such as when storage was full — the operation could in some cases be treated as successful if no OS error code was reported. This could mask an I/O failure. The update ensures partial writes are always reported as failures with a valid filesystem error, allowing NDB data nodes to respond safely and consistently.
More predictable NDBAPI workloads
NDB Cluster 9.x introduces a new data-node parameter, MaxRowVersionsPerTransaction, for workloads that repeatedly update the same row within one transaction. The parameter limits the number of row versions that may be created for that row, preventing very long update chains from extending commit or rollback cleanup in DBTUP (the data storage and update block) and DBTUX (the ordered-index block). When the configured limit is reached, NDB returns a clear error instead of allowing cleanup work to grow without bound.
Transaction activity monitoring is now decoupled from heartbeat timing. Rather than deriving histogram boundaries from the configured heartbeat interval, NDB uses stable activity boundaries, keeping `ndbinfo.transaction_activity` useful in environments where different node types use different heartbeat values.
BLOB access is more efficient for autocommit workloads. NDB removes unnecessary round trips during BLOB `close()` and `unlock()` processing, which is particularly valuable for joins that use BLOB columns.
The NDBAPI EventOperation class (https://dev.mysql.com/doc/ndbapi/en/ndb-ndbeventoperation.html) is enhanced with new methods giving users more visibility and control over the subscription behaviour around start and stop. Previously, events from transition epochs could be incomplete, which in some cases could cause NDBAPI crashes or incorrect binary log entries — particularly for tables containing BLOB columns. The update introduces controls to identify the first fully consistent event epoch and filter potentially incomplete events before it. Event merging now enables this protection automatically, improving stability for binary logging and other NDBAPI event consumers.
Faster, more controllable restores
`ndb_restore` receives a broad set of improvements for high-throughput and operationally demanding recovery workflows. Restore output can include message severity and part identifiers, making it easier to understand interleaved logs from multiple restore processes or multi-part backups. The relevant display options are enabled by default in applicable 9.x releases.
Restore execution can apply backup log records concurrently, and can optionally provide a transaction-coordinator hint using `–hint`. A configurable file read buffer gives users another way to expose restore parallelism, especially for schemas with wide rows where the default buffer can otherwise constrain concurrency.
Multi-threaded restores now make use of available parallelism. The `–parallelism` upper limit has been expanded, while work per fileset remains bounded by the underlying NDBAPI concurrency limit. This allows large multi-fileset restores to maintain more work in flight without exceeding safe per-fileset levels.
For controlled recovery scenarios, `ndb_restore` adds `–skip-fk-checks`. When foreign keys are re-enabled through index rebuilding, this option avoids checking existing restored rows for foreign-key consistency.
Easier administration and safer change planning
Users can now inspect the embedded metadata stored with an NDB schema. This is useful when assessing downgrade readiness, because it helps identify tables whose serialized dictionary information was created by a newer MySQL server.
Management node configuration also gains an option to skip connecting-host matching during node-ID allocation where a deployment explicitly requires that flexibility. This supports specialised network and deployment layouts while leaving the established behaviour available by default.
Summary
Across MySQL NDB Cluster 9.x, the common theme is operational confidence. The cluster provides more evidence when diagnosing an event, behaves more predictably when timeouts or failures occur, uses network and restore resources more effectively, and gives users better controls for demanding production environments.
For exact availability, consult the release notes for your target 9.x version; the included changes span multiple Innovation and LTS releases in the 9.x series.
https://dev.mysql.com/doc/relnotes/mysql-cluster/9.7/en/