MySQL NDB Cluster 7.3 Release Notes
After adding new data nodes to the configuration file of a MySQL
NDB Cluster having many API nodes, but prior to starting any of
the data node processes, API nodes tried to connect to these
“missing” data nodes several times per second,
placing extra loads on management nodes and the network. To
reduce unnecessary traffic caused in this way, it is now
possible to control the amount of time that an API node waits
between attempts to connect to data nodes which fail to respond;
this is implemented in two new API node configuration parameters
StartConnectBackoffMaxTime
and
ConnectBackoffMaxTime
.
Time elapsed during node connection attempts is not taken into
account when applying these parameters, both of which are given
in milliseconds with approximately 100 ms resolution. As long as
the API node is not connected to any data nodes as described
previously, the value of the
StartConnectBackoffMaxTime
parameter is
applied; otherwise, ConnectBackoffMaxTime
is
used.
In a MySQL NDB Cluster with many unstarted data nodes, the values of these parameters can be raised to circumvent connection attempts to data nodes which have not yet begun to function in the cluster, as well as moderate high traffic to management nodes.
For more information about the behavior of these parameters, see Defining SQL and Other API Nodes in an NDB Cluster. (Bug #17257842)
Added the
--exclude-missing-tables
option for ndb_restore. When enabled, the
option causes tables present in the backup but not in the target
database to be ignored.
(Bug #57566, Bug #11764704)
NDB Cluster APIs:
The fix for Bug #16723708 stopped the
ndb_logevent_get_next()
function from casting a log event's
ndb_mgm_event_category
to an
enum
type, but this change interfered with
existing applications, and so the function's original behavior
is now reinstated. A new MGM API function exhibiting the
corrected behavior
ndb_logevent_get_next2()
has
been added in this release to take the place of the reverted
function, for use in applications that do not require backward
compatibility. In all other respects apart from this, the new
function is identical with its predecessor.
(Bug #18354165)
References: Reverted patches: Bug #16723708.
NDB Cluster APIs:
NDB API scans leaked
Ndb_cluster_connection
objects
after
nextResult()
was called when an operation resulted in an error. This leak
locked up the corresponding connection objects in the
DBTC
kernel block until the connection was
closed.
(Bug #17730825, Bug #20170731)
When assembling error messages of the form Incorrect
state for node n
state:
node_state
, written when
the transporter failed to connect, the node state was used in
place of the node ID in a number of instances, which resulted in
errors of this type for which the node state was reported
incorrectly.
(Bug #19559313, Bug #73801)
In some cases, transporter receive buffers were reset by one thread while being read by another. This happened when a race condition occurred between a thread receiving data and another thread initiating disconnect of the transporter (disconnection clears this buffer). Concurrency logic has now been implemented to keep this race from taking place. (Bug #19552283, Bug #73790)
The failure of a data node could in some situations cause a set
of API nodes to fail as well due to the sending of a
CLOSE_COMREQ
signal that was sometimes not
completely initialized.
(Bug #19513967)
A more detailed error report is printed in the event of a
critical failure in one of the NDB
internal
sendSignal*()
methods, prior to crashing the
process, as was already implemented for
sendSignal()
, but was missing from the more
specialized sendSignalNoRelease()
method.
Having a crash of this type correctly reported can help with
identifying configuration hardware issues in some cases.
(Bug #19414511)
References: See also: Bug #19390895.
ndb_restore failed to restore the cluster's metadata when there were more than approximately 17 K data objects. (Bug #19202654)
The fix for a previous issue with the handling of multiple node failures required determining the number of TC instances the failed node was running, then taking them over. The mechanism to determine this number sometimes provided an invalid result which caused the number of TC instances in the failed node to be set to an excessively high value. This in turn caused redundant takeover attempts, which wasted time and had a negative impact on the processing of other node failures and of global checkpoints. (Bug #19193927)
References: This issue is a regression of: Bug #18069334.
Parallel transactions performing reads immediately preceding a
delete on the same tuple could cause the NDB
kernel to crash. This was more likely to occur when separate TC
threads were specified using the
ThreadConfig
configuration parameter.
(Bug #19031389)
Attribute promotion between different
TEXT
types (any of
TINYTEXT
,
TEXT
,
MEDIUMTEXT
, and
LONGTEXT
) by
ndb_restore was not handled properly in some
cases. In addition, TEXT
values are now
truncated according to the limits set by
mysqld (for example, values converted to
TINYTEXT
from another type are truncated to
256 bytes). In the case of columns using a multibyte character
set, the value is truncated to the end of the last well-formed
character.
Also as a result of this fix, conversion to a
TEXT
column of any size that uses a different
character set from the original is now disallowed.
(Bug #18875137)
To assist with diagnostic issues where many watchdog warnings
are raised, it is now possible to activate (or deactivate) a
killer watchdog using DUMP
2610
in the ndb_mgm client. When
set, this shuts down the data node on which the next watchdog
warning occurs, providing a trace log.
(Bug #18703922)
The NDB
optimized node recovery mechanism
attempts to transfer only relevant page changes to a starting
node in order to speed the recovery process; this is done by
having the starting node indicate the index of the last global
checkpoint (GCI) in which it participated, so that the node that
was already running copies only data for rows which have changed
since that GCI. Every row has a GCI metacolumn which facilitates
this; for a deleted row, the slot formerly stpring this row's
data contains a GCI value, and for deleted pages, every row on
the missing page is considered changed and thus needs to be
sent.
When these changes are received by the starting node, this node performs a lookup for the page and index to determine what they contain. This lookup could cause a real underlying page to be mapped against the logical page ID, even when this page contained no data.
One way in which this issue could manifest itself occurred after
cluster DataMemory
usage
approached maximum, and deletion of many rows followed by a
rolling restart of the data nodes was performed with the
expectation that this would free memory, but in fact it was
possible in this scenario for memory not to be freed and in some
cases for memory usage actually to increase to its maximum.
This fix solves these issues by ensuring that a real physical page is mapped to a logical ID during node recovery only when this page contains actual data which needs to be stored. (Bug #18683398, Bug #18731008)
When a data node sent a MISSING_DATA
signal
due to a buffer overflow and no event data had yet been sent for
the current epoch, the dummy event list created to handle this
inconsistency was not deleted after the information in the dummy
event list was transferred to the completed list.
(Bug #18410939)
Incorrect calculation of the next autoincrement value following
a manual insertion towards the end of a cached range could
result in duplicate values sometimes being used. This issue
could manifest itself when using certain combinations of values
for auto_increment_increment
,
auto_increment_offset
, and
ndb_autoincrement_prefetch_sz
.
This issue has been fixed by modifying the calculation to make
sure that the next value from the cache as computed by
NDB
is of the form
auto_increment_offset + (
. This avoids any rounding up
by the MySQL Server of the returned value, which could result in
duplicate entries when the rounded-up value fell outside the
range of values cached by N
*
auto_increment_incrementNDB
.
(Bug #17893872)
ndb_show_tables
--help
output contained
misleading information about the
--database
(-d
) option. In addition, the long form of the
option (--database
) did not work properly.
(Bug #17703874)
Using the --help
option with
ndb_print_file caused the program to
segfault.
(Bug #17069285)
For multithreaded data nodes, some threads do communicate often, with the result that very old signals can remain at the top of the signal buffers. When performing a thread trace, the signal dumper calculated the latest signal ID from what it found in the signal buffers, which meant that these old signals could be erroneously counted as the newest ones. Now the signal ID counter is kept as part of the thread state, and it is this value that is used when dumping signals for trace files. (Bug #73842, Bug #19582807)