This is a bugfix release, fixing recently discovered bugs in the previous MySQL Cluster NDB 6.2 release.
Obtaining MySQL Cluster NDB 6.2. You can download the latest MySQL Cluster NDB 6.2 source code and binaries for supported platforms from http://dev.mysql.com/downloads/select.php?id=14.
This Beta release incorporates all bugfixes and changes made in previous MySQL Cluster NDB 6.2 releases, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.22 (see Section C.1.30, “Changes in MySQL 5.1.22 (24 September 2007 Release Candidate)”).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
Functionality added or changed:
Mapping of NDB
error codes to MySQL
storage engine error codes has been improved.
(Bug#28423)
Bugs fixed:
Partitioning:
EXPLAIN
PARTITIONS
reported partition usage by queries on
NDB
tables according to the
standard MySQL hash function than the hash function used in the
NDB
storage engine.
(Bug#29550)
When an NDB
event was left behind
but the corresponding table was later recreated and received a
new table ID, the event could not be dropped.
(Bug#30877)
Attempting to restore a backup made on a cluster host using one endian to a machine using the other endian could cause the cluster to fail. (Bug#29674)
The description of the --print
option provided
in the output from ndb_restore --help
was incorrect.
(Bug#27683)
Restoring a backup made on a cluster host using one endian to a
machine using the other endian failed for
BLOB
and
DATETIME
columns.
(Bug#27543, Bug#30024)
An insufficiently descriptive and potentially misleading Error 4006 (Connect failure - out of connection objects...) was produced when either of the following two conditions occurred:
There were no more transaction records in the transaction coordinator
An NDB
object in the NDB API
was initialized with insufficient parallelism
Separate error messages are now generated for each of these two cases. (Bug#11313)
For micro-GCPs, the assignment of “fake” CGI events no longer cause buckets to be sent out of order. Now, when assigning a GCI to a non-GCI event (that is, creating a pseudo-GCI or “fake” CGI), the GCI that is to arrive is always initiated, even if no known GCI exists, which could occur in the event of a node failure. (Bug#30884)
User Comments
Add your own comment.