----- 7.4.12
Changes in MySQL Cluster NDB 7.4.12 (5.6.31-ndb-7.4.12) (2016-07-18)
MySQL Cluster NDB 7.4.12 is a new release of MySQL Cluster 7.4,
based on MySQL Server 5.6 and including features in version 7.4 of
the NDB storage engine, as well as fixing recently discovered bugs
in previous MySQL Cluster releases.
This release also incorporates all bugfixes and changes made in
previous MySQL Cluster releases, as well as all bugfixes and feature
changes which were added in mainline MySQL 5.6 through MySQL 5.6.31
(see Changes in MySQL 5.6.31 (2016-06-02)).
Functionality Added or Changed
ClusterJ: To make it easier for ClusterJ to handle fatal errors
that require the SessionFactory to be closed, a new public
method in the SessionFactory interface,
getConnectionPoolSessionCounts(), has been created. When it
returns zeros for all pooled connections, it means all sessions
have been closed, at which point the SessionFactory can be
closed and reopened. See Reconnecting to a MySQL Cluster for
more detail. (Bug #22353594)
Bugs Fixed
Incompatible Change: When the data nodes are only partially
connected to the API nodes, a node used for a pushdown join
may get its request from a transaction coordinator on a different
node, without (yet) being connected to the API node itself. In
such cases, the NodeInfo object for the requesting API node
contained no valid info about the software version of the API
node, which caused the DBSPJ block to assume (incorrectly) when
aborting to assume that the API node used NDB version 7.2.4 or
earlier, requiring the use of a backward compatability mode to
be used during query abort which sent a node failure error
instead of the real error causing the abort.
Now, whenever this situation occurs, it is assumed that, if
the NDB software version is not yet available, the API node
version is greater than 7.2.4. (Bug #23049170)
Although arguments to the DUMP command are 32-bit integers,
ndb_mgmd used a buffer of only 10 bytes when processing them.
(Bug #23708039)
During shutdown, the mysqld process could sometimes hang after
logging NDB Util: Stop ... NDB Util: Wakeup. (Bug #23343739)
References: See also: Bug #21098142.
During an online upgrade from a MySQL Cluster NDB 7.3 release
to an NDB 7.4 (or later) release, the failures of several data
nodes running the lower version during local checkpoints (LCPs),
and just prior to upgrading these nodes, led to additional node
failures following the upgrade. This was due to lingering
elements of the EMPTY_LCP protocol initiated by the older nodes
as part of an LCP-plus-restart sequence, and which is no longer
used in NDB 7.4 and later due to LCP optimizations implemented
in those versions. (Bug #23129433)
Reserved send buffer for the loopback transporter, introduced
in MySQL Cluster NDB 7.4.8 and used by API and management nodes
for administrative signals, was calculated incorrectly. (Bug
#23093656, Bug #22016081)
References: This issue is a regression of: Bug #21664515.
During a node restart, re-creation of internal triggers used
for verifying the referential integrity of foreign keys was
not reliable, because it was possible that not all distributed
TC and LDM instances agreed on all trigger identities. To fix
this problem, an extra step is added to the node restart
sequence, during which the trigger identities are determined
by querying the current master node. (Bug #23068914)
References: See also: Bug #23221573.
Following the forced shutdown of one of the 2 data nodes in a
cluster where NoOfReplicas=2, the other data node shut down as
well, due to arbitration failure. (Bug #23006431)
The ndbinfo.tc_time_track_stats table uses histogram buckets
to give a sense of the distribution of latencies. The sizes of
these buckets were also reported as HISTOGRAM BOUNDARY INFO
messages during data node startup; this printout was redundant
and so has been removed. (Bug #22819868)
A failure occurred in DBTUP in debug builds when variable-sized
pages for a fragment totalled more than 4 GB. (Bug #21313546)
mysqld did not shut down cleanly when executing ndb_index_stat.
(Bug #21098142)
References: See also: Bug #23343739.
DBDICT and GETTABINFOREQ queue debugging were enhanced as follows:
Monitoring by a data node of the progress of GETTABINFOREQ
signals can be enabled by setting DictTrace >= 2.
Added the ApiVerbose configuration parameter, which enables
NDB API debug logging for an API node where it is set
greater than or equal to 2.
Added DUMP code 1229 which shows the current state of the
GETTABINFOREQ queue. (See DUMP 1229.)
See also The DBDICT Block. (Bug #20368450)
References: See also: Bug #20368354.
Cluster API: Deletion of Ndb objects used a dispoportionately
high amount of CPU. (Bug #22986823)
----- 7.4.11
Changes in MySQL Cluster NDB 7.4.11 (5.6.29-ndb-7.4.11) (2016-04-20)
MySQL Cluster NDB 7.4.11 is a new release of MySQL Cluster 7.4,
based on MySQL Server 5.6 and including features in version 7.4 of
the NDB storage engine, as well as fixing recently discovered bugs
in previous MySQL Cluster releases.
This release also incorporates all bugfixes and changes made in
previous MySQL Cluster releases, as well as all bugfixes 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)).
Functionality Added or Changed
Cluster API: Added the Ndb::setEventBufferQueueEmptyEpoch()
method, which makes it possible to enable queuing of empty
events (event type TE_EMPTY). (Bug #22157845)
Bugs Fixed
Important Change: The minimum value for the BackupDataBufferSize
data node configuration parameter has been lowered from 2 MB
to 512 KB. The default and maximum values for this parameter
remain unchanged. (Bug #22749509)
Microsoft Windows: Performing ANALYZE TABLE on a table having
one or more indexes caused ndbmtd to fail with an InvalidAttrInfo
error due to signal corruption. This issue occurred consistently
on Windows, but could also be encountered on other platforms.
(Bug #77716, Bug #21441297)
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)
Compilation of MySQL with Visual Studio 2015 failed in
ConfigInfo.cpp, due to a change in Visual Studio's handling of
spaces and concatenation. (Bug #22558836, Bug #80024)
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.
When setting up event logging for ndb_mgmd on Windows, MySQL
Cluster tries to add a registry key to HKEY_LOCAL_MACHINE,
which fails if the user does not have access to the registry.
In such cases ndb_mgmd logged the error Could neither create
or open key, which is not accurate and which can cause confusion
for users who may not realize that file logging is available
and being used. Now in such cases, ndb_mgmd logs a warning
Could not create or access the registry key needed for the
application to log to the Windows EventLog. Run the application
with sufficient privileges once to create the key, or add the
key manually, or turn off logging for that application. An
error (as opposed to a warning) is now reported in such cases
only if there is no available output at all for ndb_mgmd event
logging. (Bug #20960839)
NdbDictionary metadata operations had a hard-coded 7-day timeout,
which proved to be excessive for short-lived operations such
as retrieval of table definitions. This could lead to unnecessary
hangs in user applications which were difficult to detect and
handle correctly. To help address this issue, timeout behaviour
is modified so that read-only or short-duration dictionary
interactions have a 2-minute timeout, while schema transactions
of potentially long duration retain the existing 7-day timeout.
Such timeouts are intended as a safety net: In the event of
problems, these return control to users, who can then take
corrective action. Any reproducible issue with NdbDictionary
timeouts should be reported as a bug. (Bug #20368354)
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)
An internal function used to validate connections failed to
update the connection count when creating a new Ndb object.
This had the potential to create a new Ndb object for every
operation validating the connection, which could have an impact
on performance, particularly when performing schema operations.
(Bug #80750, Bug #22932982)
When an SQL node was started, and joined the schema distribution
protocol, another SQL node, already waiting for a schema change
to be distributed, timed out during that wait. This was because
the code incorrectly assumed that the new SQL node would also
acknowledge the schema distribution even though the new node
joined too late to be a participant in it.
As part of this fix, printouts of schema distribution progress
now always print the more significant part of a bitmask before
the less significant; formatting of bitmasks in such printouts
has also been improved. (Bug #80554, Bug #22842538)
Settings for the SchedulerResponsiveness data node configuration
parameter (introduced in MySQL Cluster NDB 7.4.9) were ignored.
(Bug #80341, Bug #22712481)
MySQL Cluster did not compile correctly with Microsoft Visual
Studio 2015, due to a change from previous versions in the VS
implementation of the _vsnprintf() function. (Bug #80276, Bug
#22670525)
When setting CPU spin time, the value was needlessly cast to
a boolean internally, so that setting it to any nonzero value
yielded an effective value of 1. This issue, as well as the
fix for it, apply both to setting the SchedulerSpinTimer
parameter and to setting spintime as part of a ThreadConfig
parameter value. (Bug #80237, Bug #22647476)
Processing of local checkpoints was not handled correctly on
Mac OS X, due to an uninitialized variable. (Bug #80236, Bug
#22647462)
A logic error in an if statement in
storage/ndb/src/kernel/blocks/dbacc/DbaccMain.cpp rendered
useless a check for determining whether ZREAD_ERROR should be
returned when comparing operations. This was detected when
compiling with gcc using -Werror=logical-op. (Bug #80155, Bug
#22601798)
References: This issue is a regression of: Bug #21285604.
The ndb_print_file utility failed consistently on Solaris 9
for SPARC. (Bug #80096, Bug #22579581)
Builds with the -Werror and -Wextra flags (as for release
builds) failed on SLES 11. (Bug #79950, Bug #22539531)
When using CREATE INDEX to add an index on either of two NDB
tables sharing circular foreign keys, the query succeeded but
a temporary table was left on disk, breaking the foreign key
constraints. This issue was also observed when attempting to
create an index on a table in the middle of a chain of foreign
keysthat is, a table having both parent and child keys, but on
different tables. The problem did not occur when using ALTER
TABLE to perform the same index creation operation; and subsequent
analysis revealed unintended differences in the way such
operations were performed by CREATE INDEX.
To fix this problem, we now make sure that operations performed
by a CREATE INDEX statement are always handled internally in
the same way and at the same time that the same operations are
handled when performed by ALTER TABLE or DROP INDEX. (Bug
#79156, Bug #22173891)
NDB failed to ignore index prefixes on primary and unique keys,
causing CREATE TABLE and ALTER TABLE statements using them to
be rejected. (Bug #78441, Bug #21839248)
Cluster API: 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)
Integer overflow could occur during client handshake processing,
leading to a server exit. (Bug #22722946)
For busy servers, client connection or communication failure
could occur if an I/O-related system call was interrupted. The
mysql_options() C API function now has a MYSQL_OPT_RETRY_COUNT
option to control the number of retries for interrupted system
calls. (Bug #22336527)
References: See also: Bug #22389653.
c49d8591ba