This is a bugfix release, fixing recently discovered bugs in the previous MySQL Cluster NDB 6.3 release.
Obtaining MySQL Cluster NDB 6.3.20. You can download MySQL Cluster NDB 6.3.20 source code and binaries for supported platforms from http://dev.mysql.com/downloads/select.php?id=14.
This release incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.3 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.30 (see Section C.1.22, “Changes in MySQL 5.1.30 (14 November 2008 General Availability)”).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Bugs fixed:
If a transaction was aborted during the handling of a data node failure, this could lead to the later handling of an API node failure not being completed. (Bug#41214)
Issuing SHOW TABLES
repeatedly could cause
NDBCLUSTER
tables to be dropped.
(Bug#40854)
Statements of the form UPDATE ... ORDER BY ...
LIMIT
run against
NDBCLUSTER
tables failed to update
all matching rows, or failed with the error Can't
find record in
'table_name
'.
(Bug#40081)
Start phase reporting was inconsistent between the management client and the cluster log. (Bug#39667)
Status messages shown in the management client when restarting a
management node were inappropriate and misleading. Now, when
restarting a management node, the messages displayed are as
follows, where node_id
is the
management node's node ID:
ndb_mgm>Shutting down MGM node
node_id
RESTARTnode_id
for restart Nodenode_id
is being restarted ndb_mgm>
Partitioning: A query on a user-partitioned table caused MySQL to crash, where the query had the following characteristics:
The query's WHERE
clause referenced
an indexed column that was also in the partitioning key.
The query's WHERE
clause included a
value found in the partition.
The query's WHERE
clause used the
<
or <>
operators to compare with the indexed column's value
with a constant.
The query used an ORDER BY
clause, and
the same indexed column was used in the ORDER
BY
clause.
The ORDER BY
clause used an explcit or
implicit ASC
sort priority.
Two examples of such a query are given here, where
a
represents an indexed column used in the
table's partitioning key:
SELECT * FROMtable
WHERE a <constant
ORDER BY a;
SELECT * FROMtable
WHERE a <>constant
ORDER BY a;
This bug was introduced in MySQL Cluster NDB 6.3.19. (Bug#40954)
This regression was introduced by Bug#30573, Bug#33257, Bug#33555.
Replication:
Issuing the statement CHANGE MASTER TO ...
MASTER_HEARTBEAT_PERIOD =
using a value for
period
period
outside the permitted range
caused the slave to crash.
(Bug#39077)
Disk Data: This improves on a previous fix for this issue that was made in MySQL Cluster 6.3.8. (Bug#37116)
See also Bug#29186.
Cluster API:
When creating a scan using an NdbScanFilter
object, it was possible to specify conditions against a
BIT
column, but the correct rows were not
returned when the scan was executed.
As part of this fix, 4 new comparison operators have been
implemented for use with scans on BIT
columns:
COL_AND_MASK_EQ_MASK
COL_AND_MASK_NE_MASK
COL_AND_MASK_EQ_ZERO
COL_AND_MASK_NE_ZERO
For more information about these operators, see
The NdbScanFilter::BinaryCondition
Type.
Equivalent methods are now also defined for
NdbInterpretedCode
; for more information, see
NdbInterpretedCode
Bitwise Comparison Operations.
(Bug#40535)
User Comments
Add your own comment.