MySQL NDB Cluster 7.6 Release Notes
MySQL NDB Cluster 7.6.16 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.32 (see Changes in MySQL 5.7.32 (2020-10-19, General Availability)).
NDB Cluster APIs: Support for Node.js has been removed in this release.
Node.js continues to be supported in NDB Cluster 8.0 only. (Bug #31781948)
NDB Client Programs: Effective with this release, the MySQL NDB Cluster Auto-Installer (ndb_setup.py) has been deprecated and is subject to removal in a future version of NDB Cluster. (Bug #31888835)
ndbmemcache:
ndbmemcache
is deprecated in this release of
NDB Cluster, and is scheduled for removal in the next release.
(Bug #31876970)
Packaging: The Dojo library included with NDB Cluster has been upgraded to version 1.15.4. (Bug #31559518)
NDB Cluster APIs:
In certain cases, the
Table::getColumn()
method
returned the wrong Column
object. This could happen when the full name of one table column
was a prefix of the name of another, or when the names of two
columns had the same hash value.
(Bug #31774685)
NDB Cluster APIs: It was possible to make invalid sequences of NDB API method calls using blobs. This was because some method calls implicitly cause transaction execution inline, to deal with blob parts and other issues, which could cause user-defined operations not to be handled correctly due to the use of a method executing operations relating to blobs while there still user-defined blob operations pending. Now in such cases, NDB raises a new error 4558 Pending blob operations must be executed before this call. (Bug #27772916)
After encountering the data node in the configuration file which
used NodeGroup=65536
,
the management server stopped assigning data nodes lacking an
explicit NodeGroup
setting to node groups.
(Bug #31825181)
In some cases, QMGR
returned
conflicting NDB
engine and MySQL
server version information, which could lead to unplanned
management node shutdown.
(Bug #31471959)
During different phases of the restore process, ndb_restore used different numbers of retries for temporary errors as well as different sleep times between retries. This is fixed by implementing consistent retry counts and sleep times across all restore phases. (Bug #31372923)
Backups errored out with
FsErrInvalidParameters when the
filesystem was running with O_DIRECT
and a
data file write was not aligned with the 512-byte block size
used by O_DIRECT
writes. If the total
fragment size in the data file is not aligned with the
O_DIRECT
block size, NDB
pads the last write to the required size, but when there were no
fragments to write, BACKUP
wrote only the header and footer to the data file. Since the
header and footer are less than 512 bytes, leading to the issue
with the O_DIRECT
write.
This is fixed by padding out the generic footer to 512 bytes if
necessary, using an EMPTY_ENTRY
, when closing
the data file.
(Bug #31180508)
Altering the table comment of a fully replicated table using
ALGORITHM=INPLACE
led to an assertion.
(Bug #31139313)
Data nodes did not start when the
RealtimeScheduler
configuration parameter was set to 1. This was due to the fact
that index builds during startup are performed by temporarily
diverting some I/O threads for use as index building threads,
and these threads inherited the realtime properties of the I/O
threads. This caused a conflict (treated as a fatal error) when
index build thread specifications were checked to ensure that
they were not realtime threads. This is fixed by making sure
that index build threads are not treated as realtime threads
regardless of any settings applying to their host I/O threads,
which is as actually intended in their design.
(Bug #27533538)