MySQL NDB Cluster 7.3 Release Notes
MySQL NDB Cluster 7.3.16 is a new release of NDB Cluster, based on
MySQL Server 5.6 and including features from version 7.3 of the
NDB
storage engine, as well as fixing
a number of recently discovered bugs in previous NDB Cluster
releases.
Obtaining MySQL NDB Cluster 7.3. MySQL NDB Cluster 7.3 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.3, see What is New in NDB Cluster 7.3.
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.6 through MySQL 5.6.35 (see Changes in MySQL 5.6.35 (2016-12-12, General Availability)).
ndb_restore did not restore tables having
more than 341 columns correctly. This was due to the fact that
the buffer used to hold table metadata read from
.ctl
files was of insufficient size, so
that only part of the table descriptor could be read from it in
such cases. This issue is fixed by increasing the size of the
buffer used by ndb_restore for file reads.
(Bug #25182956)
References: See also: Bug #25302901.
The rand()
function was used to produce a
unique table ID and table version needed to identify a schema
operation distributed between multiple SQL nodes, relying on the
assumption that rand()
would never produce
the same numbers on two different instances of mysqld. It was
later determined that this is not the case, and that in fact it
is very likely for the same random numbers to be produced on all
SQL nodes.
This fix removes the usage of rand()
for
producing a unique table ID or version, and instead uses a
sequence in combination with the node ID of the coordinator.
This guarantees uniqueness until the counter for the sequence
wraps, which should be sufficient for this purpose.
The effects of this duplication could be observed as timeouts in
the log (for example NDB create db: waiting max 119
sec for distributing) when restarting multiple
mysqld processes simultaneously or nearly so,
or when issuing the same CREATE
DATABASE
or DROP
DATABASE
statement on multiple SQL nodes.
(Bug #24926009)
Long message buffer exhaustion when firing immediate triggers
could result in row ID leaks; this could later result in
persistent RowId already allocated errors
(NDB
Error 899).
(Bug #23723110)
References: See also: Bug #19506859, Bug #13927679.
when a parent NDB
table in a
foreign key relationship was updated, the update cascaded to a
child table as expected, but the change was not cascaded to a
child table of this child table (that is, to a grandchild of the
original parent). This can be illustrated using the tables
generated by the following CREATE
TABLE
statements:
CREATE TABLE parent( id INT PRIMARY KEY AUTO_INCREMENT, col1 INT UNIQUE, col2 INT ) ENGINE NDB; CREATE TABLE child( ref1 INT UNIQUE, FOREIGN KEY fk1(ref1) REFERENCES parent(col1) ON UPDATE CASCADE ) ENGINE NDB; CREATE TABLE grandchild( ref2 INT, FOREIGN KEY fk2(ref2) REFERENCES child(ref1) ON UPDATE CASCADE ) ENGINE NDB;
Table child
is a child of table
parent
; table grandchild
is a child of table child
, and a grandchild
of parent
. In this scenario, a change to
column col1
of parent
cascaded to ref1
in table
child
, but it was not always propagated in
turn to ref2
in table
grandchild
.
(Bug #83743, Bug #25063506)