MySQL NDB Cluster 7.3 Release Notes
MySQL NDB Cluster 7.3.13 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.29 (see Changes in MySQL 5.6.29 (2016-02-05, General Availability)).
NDB Cluster APIs:
Executing a transaction with an
NdbIndexOperation
based on an
obsolete unique index caused the data node process to fail. Now
the index is checked in such cases, and if it cannot be used the
transaction fails with an appropriate error.
(Bug #79494, Bug #22299443)
During node failure handling, the request structure used to drive the cleanup operation was not maintained correctly when the request was executed. This led to inconsistencies that were harmless during normal operation, but these could lead to assertion failures during node failure handling, with subsequent failure of additional nodes. (Bug #22643129)
The previous fix for a lack of mutex protection for the internal
TransporterFacade::deliver_signal()
function
was found to be incomplete in some cases.
(Bug #22615274)
References: This issue is a regression of: Bug #77225, Bug #21185585.
When setup of the binary log as an atomic operation on one SQL node failed, this could trigger a state in other SQL nodes in which they appeared to detect the SQL node participating in schema change distribution, whereas it had not yet completed binary log setup. This could in turn cause a deadlock on the global metadata lock when the SQL node still retrying binary log setup needed this lock, while another mysqld had taken the lock for itself as part of a schema change operation. In such cases, the second SQL node waited for the first one to act on its schema distribution changes, which it was not yet able to do. (Bug #22494024)
Duplicate key errors could occur when
ndb_restore was run on a backup containing a
unique index. This was due to the fact that, during restoration
of data, the database can pass through one or more inconsistent
states prior to completion, such an inconsistent state possibly
having duplicate values for a column which has a unique index.
(If the restoration of data is preceded by a run with
--disable-indexes
and
followed by one with
--rebuild-indexes
, these
errors are avoided.)
Added a check for unique indexes in the backup which is performed only when restoring data, and which does not process tables that have explicitly been excluded. For each unique index found, a warning is now printed. (Bug #22329365)
Restoration of metadata with ndb_restore
-m
occasionally failed with the error message Failed to
create index... when creating a unique index. While
disgnosing this problem, it was found that the internal error
PREPARE_SEIZE_ERROR (a temporary error)
was reported as an unknown error. Now in such cases,
ndb_restore retries the creation of the
unique index, and PREPARE_SEIZE_ERROR is
reported as NDB Error 748 Busy during read of event
table.
(Bug #21178339)
References: See also: Bug #22989944.
Optimization of signal sending by buffering and sending them
periodically, or when the buffer became full, could cause
SUB_GCP_COMPLETE_ACK
signals to be
excessively delayed. Such signals are sent for each node and
epoch, with a minimum interval of
TimeBetweenEpochs
; if
they are not received in time, the SUMA
buffers can overflow as a result. The overflow caused API nodes
to be disconnected, leading to current transactions being
aborted due to node failure. This condition made it difficult
for long transactions (such as altering a very large table), to
be completed. Now in such cases, the ACK
signal is sent without being delayed.
(Bug #18753341)