MySQL NDB Cluster 7.2 Release Notes
MySQL NDB Cluster 7.2.14 is a new release of NDB Cluster,
incorporating new features in the NDB
storage engine, and fixing recently discovered bugs in previous
MySQL NDB Cluster 7.2 development releases.
Obtaining MySQL NDB Cluster 7.2. MySQL NDB Cluster 7.2 source code and binaries can be obtained from https://dev.mysql.com/downloads/cluster/.
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.5 through MySQL 5.5.34 (see Changes in MySQL 5.5.34 (2013-09-20, General Availability)).
Added the ExtraSendBufferMemory
parameter for
management nodes and API nodes. (Formerly, this parameter was
available only for configuring data nodes.) See
ExtraSendBufferMemory
(management nodes), and
ExtraSendBufferMemory
(API nodes), for more information.
(Bug #14555359)
BLOB
and
TEXT
columns are now reorganized
by the
ALTER
ONLINE TABLE ... REORGANIZE PARTITION
statement.
(Bug #13714148)
Performance: In a number of cases found in various locations in the MySQL NDB Cluster codebase, unnecessary iterations were performed; this was caused by failing to break out of a repeating control structure after a test condition had been met. This community-contributed fix removes the unneeded repetitions by supplying the missing breaks. (Bug #16904243, Bug #69392, Bug #16904338, Bug #69394, Bug #16778417, Bug #69171, Bug #16778494, Bug #69172, Bug #16798410, Bug #69207, Bug #16801489, Bug #69215, Bug #16904266, Bug #69393)
Packaging; Microsoft Windows:
The MySQL NDB Cluster installer for Windows provided a
nonfunctional option to install debug symbols (contained in
*.pdb
files). This option has been removed
from the installer.
You can obtain the *.pdb
debug files for
a given MySQL NDB Cluster release from the Windows
.zip
archive for the same release, such
as mysql-cluster-gpl-7.2.14-win32.zip
or
mysql-cluster-gpl-7.3.2-winx64.zip
.
(Bug #16748308, Bug #69112)
Packaging; Microsoft Windows:
The MySQL NDB Cluster Windows installer attempted to use the
wrong path to the my.ini
file and the
executables directory.
(Bug #13813120, Bug #64510)
Packaging:
A fix has been made in this release correcting a number of
issues found in some recent
MySQL-Cluster-server
RPM packages, including
dependencies on the mysql-server
package and
conflicts with the mysql-libs
package needed
by other common applications. Platforms known to have been
affected by these issues include CentOS 6, Red Hat Enterprise
Linux 6, and Oracle Linux 6.
(Bug #14063590, Bug #14181419, Bug #65534)
Microsoft Windows:
The Windows error ERROR_FILE_EXISTS was
not recognized by NDB
, which
treated it as an unknown error.
(Bug #16970960)
NDB Disk Data:
The statements CREATE TABLESPACE
,
ALTER LOGFILE GROUP
, and
ALTER TABLESPACE
failed with a
syntax error when INITIAL_SIZE
was specified
using letter abbreviations such as M
or
G
. In addition, CREATE
LOGFILE GROUP
failed when
INITIAL_SIZE
,
UNDO_BUFFER_SIZE
, or both options were
specified using letter abbreviations.
(Bug #13116514, Bug #16104705, Bug #62858)
NDB Replication:
Trying to use a stale .frm
file and
encountering a mismatch bewteen table definitions could cause
mysqld to make errors when writing to the
binary log.
(Bug #17250994)
NDB Replication: Replaying a binary log that had been written by a mysqld from a MySQL Server distribution (and from not a MySQL NDB Cluster distribution), and that contained DML statements, on a MySQL NDB Cluster SQL node could lead to failure of the SQL node. (Bug #16742250)
NDB Cluster APIs:
For each log event retrieved using the MGM API, the log event
category
(ndb_mgm_event_category
) was
simply cast to an enum
type, which resulted
in invalid category values. Now an offset is added to the
category following the cast to ensure that the value does not
fall out of the allowed range.
This change was reverted by the fix for Bug #18354165. See the
MySQL NDB Cluster API Developer documentation for
ndb_logevent_get_next()
, for
more information.
(Bug #16723708)
References: See also: Bug #18354165.
NDB Cluster APIs:
The Event::setTable()
method
now supports a pointer or a reference to table as its required
argument. If a null table pointer is used, the method now
returns -1 to make it clear that this is what has occurred.
(Bug #16329082)
ndbmemcache:
The CMakeLists.txt
files for
ndbmemcache
wrote into the source tree,
preventing out-of-source builds.
(Bug #14650456)
ndbmemcache:
ndbmemcache
did not handle passed-in
BINARY
values correctly.
Trying to restore to a table having a
BLOB
column in a different
position from that of the original one caused
ndb_restore
--restore-data
to fail.
(Bug #17395298)
ndb_restore could abort during the last stages of a restore using attribute promotion or demotion into an existing table. This could happen if a converted attribute was nullable and the backup had been run on active database. (Bug #17275798)
The DBUTIL
data node block is now less strict
about the order in which it receives certain messages from other
nodes.
(Bug #17052422)
RealTimeScheduler
did
not work correctly with data nodes running
ndbmtd.
(Bug #16961971)
File system errors occurring during a local checkpoint could sometimes cause an LCP to hang with no obvious cause when they were not handled correctly. Now in such cases, such errors always cause the node to fail. Note that the LQH block always shuts down the node when a local checkpoint fails; the change here is to make likely node failure occur more quickly and to make the original file system error more visible. (Bug #16961443)
mysql_upgrade failed when upgrading from
MySQL NDB Cluster 7.1.26 to MySQL NDB Cluster 7.2.13 when it
attempted to invoke a stored procedure before the
mysql.proc
table had been upgraded.
(Bug #16933405)
References: This issue is a regression of: Bug #16226274.
The planned or unplanned shutdown of one or more data nodes
while reading table data from the
ndbinfo
database caused a
memory leak.
(Bug #16932989)
Maintenance and checking of parent batch completion in the
SPJ
block of the NDB
kernel was reimplemented. Among other improvements, the
completion state of all ancestor nodes in the tree are now
preserved.
(Bug #16925513)
Executing DROP TABLE
while
DBDIH
was updating table checkpoint
information subsequent to a node failure could lead to a data
node failure.
(Bug #16904469)
In certain cases, when starting a new SQL node, mysqld failed with Error 1427 Api node died, when SUB_START_REQ reached node. (Bug #16840741)
Failure to use container classes specific
NDB
during node failure handling
could cause leakage of commit-ack markers, which could later
lead to resource shortages or additional node crashes.
(Bug #16834416)
Use of an uninitialized variable employed in connection with
error handling in the DBLQH
kernel block
could sometimes lead to a data node crash or other stability
issues for no apparent reason.
(Bug #16834333)
A race condition in the time between the reception of a
execNODE_FAILREP
signal by the
QMGR
kernel block and its reception by the
DBLQH
and DBTC
kernel
blocks could lead to data node crashes during shutdown.
(Bug #16834242)
The CLUSTERLOG
command (see
Commands in the NDB Cluster Management Client) caused
ndb_mgm to crash on Solaris SPARC systems.
(Bug #16834030)
The NDB Error-Reporting Utility
(ndb_error_reporter) failed to include the
cluster nodes' log files in the archive it produced when the
FILE
option was set for the parameter
LogDestination
.
(Bug #16765651)
References: See also: Bug #11752792, Bug #44082.
The LCP fragment scan watchdog periodically checks for lack of
progress in a fragment scan performed as part of a local
checkpoint, and shuts down the node if there is no progress
after a given amount of time has elapsed. This interval,
formerly hard-coded as 60 seconds, can now be configured using
the
LcpScanProgressTimeout
data node configuration parameter added in this release.
This configuration parameter sets the maximum time the local checkpoint can be stalled before the LCP fragment scan watchdog shuts down the node. The default is 60 seconds, which provides backward compatibility with previous releases.
You can disable the LCP fragment scan watchdog by setting this parameter to 0. (Bug #16630410)
Added the ndb_error_reporter options
--connection-timeout
,
which makes it possible to set a timeout for connecting to
nodes, --dry-scp
,
which disables scp connections to remote hosts, and
--skip-nodegroup
,
which skips all nodes in a given node group.
(Bug #16602002)
References: See also: Bug #11752792, Bug #44082.
After issuing START BACKUP
, if
id
WAIT STARTEDid
had already been used for a backup
ID, an error caused by the duplicate ID occurred as expected,
but following this, the START BACKUP
command
never completed.
(Bug #16593604, Bug #68854)
ndb_mgm treated backup IDs provided to
ABORT BACKUP
commands as signed values, so
that backup IDs greater than 231
wrapped around to negative values. This issue also affected
out-of-range backup IDs, which wrapped around to negative values
instead of causing errors as expected in such cases. The backup
ID is now treated as an unsigned value, and
ndb_mgm now performs proper range checking
for backup ID values greater than MAX_BACKUPS
(232).
(Bug #16585497, Bug #68798)
When trying to specify a backup ID greater than the maximum allowed, the value was silently truncated. (Bug #16585455, Bug #68796)
The unexpected shutdown of another data node as a starting data node received its node ID caused the latter to hang in Start Phase 1. (Bug #16007980)
References: See also: Bug #18993037.
SELECT ... WHERE ...
LIKE
from an NDB
table
could return incorrect results when using
engine_condition_pushdown=ON
.
(Bug #15923467, Bug #67724)
The NDB
receive thread waited unnecessarily
for additional job buffers to become available when receiving
data. This caused the receive mutex to be held during this wait,
which could result in a busy wait when the receive thread was
running with real-time priority.
This fix also handles the case where a negative return value
from the initial check of the job buffer by the receive thread
prevented further execution of data reception, which could
possibly lead to communication blockage or configured
ReceiveBufferMemory
underutilization.
(Bug #15907515)
When the available job buffers for a given thread fell below the critical threshold, the internal multithreading job scheduler waited for job buffers for incoming rather than outgoing signals to become available, which meant that the scheduler waited the maximum timeout (1 millisecond) before resuming execution. (Bug #15907122)
Under some circumstances, a race occurred where the wrong
watchdog state could be reported. A new state name
Packing Send Buffers
is added for watchdog
state number 11, previously reported as Unknown
place
. As part of this fix, the state numbers for
states without names are always now reported in such cases.
(Bug #14824490)
Creating more than 32 hash maps caused data nodes to fail.
Usually new hashmaps are created only when performing
reorganzation after data nodes have been added or when explicit
partitioning is used, such as when creating a table with the
MAX_ROWS
option, or using PARTITION
BY KEY() PARTITIONS
.
(Bug #14710311)n
When a node fails, the Distribution Handler
(DBDIH
kernel block) takes steps together
with the Transaction Coordinator (DBTC
) to
make sure that all ongoing transactions involving the failed
node are taken over by a surviving node and either committed or
aborted. Transactions taken over which are then committed belong
in the epoch that is current at the time the node failure
occurs, so the surviving nodes must keep this epoch available
until the transaction takeover is complete. This is needed to
maintain ordering between epochs.
A problem was encountered in the mechanism intended to keep the current epoch open which led to a race condition between this mechanism and that normally used to declare the end of an epoch. This could cause the current epoch to be closed prematurely, leading to failure of one or more surviving data nodes. (Bug #14623333, Bug #16990394)
When performing an
INSERT ...
ON DUPLICATE KEY UPDATE
on an
NDB
table where the row to be
inserted already existed and was locked by another transaction,
the error message returned from the INSERT
following the timeout was Transaction already
aborted instead of the expected Lock wait
timeout exceeded.
(Bug #14065831, Bug #65130)
When using dynamic listening ports for accepting connections from API nodes, the port numbers were reported to the management server serially. This required a round trip for each API node, causing the time required for data nodes to connect to the management server to grow linearly with the number of API nodes. To correct this problem, each data node now reports all dynamic ports at once. (Bug #12593774)
ndb_error-reporter did not support the
--help
option.
(Bug #11756666, Bug #48606)
References: See also: Bug #11752792, Bug #44082.
When START BACKUP WAIT STARTED
was run from
the command line using ndb_mgm
--execute
(-e
),
the client did not exit until the backup completed.
(Bug #11752837, Bug #44146)
Formerly, the node used as the coordinator or leader for
distributed decision making between nodes (also known as the
DICT
manager—see
The DBDICT Block) was
indicated in the output of the ndb_mgm client
SHOW
command as the “master”
node, although this node has no relationship to a master server
in MySQL Replication. (It should also be noted that it is not
necessary to know which node is the leader except when debugging
NDBCLUSTER
source code.) To avoid possible
confusion, this label has been removed, and the leader node is
now indicated in SHOW
command output using an
asterisk (*
) character.
(Bug #11746263, Bug #24880)
Program execution failed to break out of a loop after meeting a desired condition in a number of internal methods, performing unneeded work in all cases where this occurred. (Bug #69610, Bug #69611, Bug #69736, Bug #17030606, Bug #17030614, Bug #17160263)
ABORT BACKUP
in the
ndb_mgm client (see
Commands in the NDB Cluster Management Client) took an
excessive amount of time to return (approximately as long as the
backup would have required to complete, had it not been
aborted), and failed to remove the files that had been generated
by the aborted backup.
(Bug #68853, Bug #17719439)
Attribute promotion and demotion when restoring data to
NDB
tables using
ndb_restore
--restore-data
with the
--promote-attributes
and
--lossy-conversions
options
has been improved as follows:
Columns of types CHAR
, and
VARCHAR
can now be promoted
to BINARY
and
VARBINARY
, and columns of the
latter two types can be demoted to one of the first two.
Note that converted character data is not checked to conform to any character set.
Any of the types CHAR
,
VARCHAR
, BINARY
, and
VARBINARY
can now be promoted to
TEXT
or
BLOB
.
When performing such promotions, the only other sort of type conversion that can be performed at the same time is between character types and binary types.