MySQL NDB Cluster 8.4 Release Notes
MySQL NDB Cluster 8.4.3 is a new LTS release of NDB 8.4, based on
MySQL Server 8.4 and including features in version 8.4 of the
NDB
storage engine, as well as fixing
recently discovered bugs in previous NDB Cluster releases.
Obtaining MySQL NDB Cluster 8.4. NDB Cluster 8.4 source code and binaries can be obtained from https://dev.mysql.com/downloads/cluster/.
For an overview of major changes made in NDB Cluster 8.4, see What is New in MySQL NDB Cluster 8.4.
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 8.4 through MySQL 8.4.3 (see Changes in MySQL 8.4.3 (2024-10-15, LTS Release)).
NDB Client Programs: The ndb_size.pl utility is now deprecated and is no longer supported. You can expect it to be removed from a future version of the NDB Cluster distribution; for this reason, you should now modify any applications which depend on it accordingly. (WL #16456)
Use of an Ndb.cfg
file for setting the
connection string for an NDB process was not well documented or
supported. With this release, this file is now formally
deprecated, and you should expect support for it to be removed
in a future release of MySQL Cluster.
(WL #15765)
The ndbcluster
plugin subscribes to all
changes that occur in NDB
and writes them
epoch by epoch to the binary log. Each epoch received from
NDB
consists of a large number of changes,
all of which are written to the binary log transaction cache
before flushing them to the binary log. Previously, it was
possible to configure the cache size for all threads, which
often led to improper resource allocation for a MySQL Server
used for writing a binary log of changes for
NDB
.
To enable dimensioning and configuring the system properly, we
introduce a new system variable
ndb_log_cache_size
which makes
it possible to set the size of the transaction cache used by the
NDB
binary log injector, so that this size
can be set separately for writing the binary log for NDB
transactions and (using
binlog_cache_size
) for writing
other transactions whose sizes are likely to be smaller.
(Bug #36694848)
NDB Cluster APIs:
Using NdbRecord
and
OO_SETVALUE
from the NDB API to write the
value of a Varchar
,
Varbinary
, Longvarchar
, or
Longvarbinary
column failed with error
829
.
(Bug #36989337)
MySQL NDB ClusterJ: References to ClusterJPA and OpenJPA have been removed from the comments in the packaging files, as JPA code was already removed from ClusterJ some time ago. (Bug #36725675)
MySQL NDB ClusterJ:
ReconnectTest
in the ClusterJ test suite
failed sometimes due to a race condition. The test has been
rewritten with proper synchronization.
(Bug #28550140)
Removed node management code from
TRIX
that was not actually
used.
(Bug #37006547)
Submitting concurrent shutdown commands for individual nodes
using ndb_mgm
SHUTDOWN
or the MGM API
sometimes had one or both of the following adverse results:
node_id
Cluster failure when all nodes in the same node group were stopped
Inability to recover when all nodes in the same node group were stopped, and the cluster had more than one node group
This was due to the fact that the (planned) shutdown of a single node assumed that only one such shutdown occurred at a time, but did not actually check this limitation.
We fix this so that concurrent single-node shutdown requests are serialized across the cluster, and any which would cause a cluster outage are rejected. (Bug #36943756)
References: See also: Bug #36839995.
Shutdown of a data node late in a schema transaction updating index statistics caused the president node to shut down as well. (Bug #36886242)
References: See also: Bug #36877952.
It was possible for duplicate events to be sent to user applications when a data node was shut down. (Bug #36750146)
BLOB_INLINE_SIZE=0
set within a column
comment was not honored, and the default for the blob type was
used instead (such as 256 bytes for
BLOB
).
See NDB_COLUMN Options, for more information. (Bug #36724336)
Issues arose when an attempt was made to use a SHM transporter's wakeup socket before it was ready, due in part to error-handling when setting up the SHM transporter, which did not close the socket correctly prior to making another attempt at setup. (Bug #36568752, Bug #36623058)
An error in a my.cnf
file could cause the
management node to shut down unexpectedly.
(Bug #36508565)
A race condition sometimes occurred between the watchdog thread and the signal execution thread trying to start node failure handling in parallel. (Bug #35728261)