Skip navigation links
MySQL 5.1 Reference Manual :: 17 MySQL Cluster NDB 6.X/7.X :: 17.7 Changes in MySQL Cluster NDB 6.X and 7.X :: 17.7.3 Changes in MySQL Cluster NDB 6.3 :: 17.7.3.25 Changes in MySQL Cluster NDB 6.3.15 (5.1.24-ndb-6.3.15) (30 May 2008)
17.7.3.26 Changes in MySQL Cluster NDB 6.3.14 (5.1.24-ndb-6.3.14) (11 May 2008) »
Section Navigation      [Toggle]

17.7.3.25. Changes in MySQL Cluster NDB 6.3.15 (5.1.24-ndb-6.3.15) (30 May 2008)

This is a new source release, fixing recently discovered bugs in previous MySQL Cluster NDB 6.3 releases.

Obtaining MySQL Cluster NDB 6.3.  This is a source-only release, which you must compile and install using the instructions found in Section 2.3, “MySQL Installation Using a Source Distribution”, and in Section 17.2.1, “MySQL Cluster Multi-Computer Installation”. You can download the GPL source tarball from the MySQL FTP site at ftp://ftp.mysql.com/pub/mysql/download/cluster_telco/.

This release incorporates all bugfixes and changes made in the previous MySQL Cluster NDB 6.3 release, as well as all bugfixes and feature changes which were added in mainline MySQL 5.1 through MySQL 5.1.24 (see Section C.1.28, “Changes in MySQL 5.1.24 (08 April 2008)”).

Note

Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.

Bugs fixed:

  • In certain rare situations, ndb_size.pl could fail with the error Can't use string ("value") as a HASH ref while "strict refs" in use. (Bug#43022)

  • Under some circumstances, a failed CREATE TABLE could mean that subsequent CREATE TABLE statements caused node failures. (Bug#37092)

  • A fail attempt to create an NDB table could in some cases lead to resource leaks or cluster failures. (Bug#37072)

  • Attempting to create a native backup of NDB tables having a large number of NULL columns and data could lead to node failures. (Bug#37039)

  • Checking of API node connections was not efficiently handled. (Bug#36843)

  • Attempting to delete a nonexistent row from a table containing a TEXT or BLOB column within a transaction caused the transaction to fail. (Bug#36756)

    See also Bug#36851.

  • If the combined total of tables and indexes in the cluster was greater than 4096, issuing START BACKUP caused data nodes to fail. (Bug#36044)

  • Where column values to be compared in a query were of the VARCHAR or VARBINARY types, NDBCLUSTER passed a value padded to the full size of the column, which caused unnecessary data to be sent to the data nodes. This also had the effect of wasting CPU and network bandwidth, and causing condition pushdown to be disabled where it could (and should) otherwise have been applied. (Bug#35393)

  • When dropping a table failed for any reason (such as when in single user mode) then the corresponding .ndb file was still removed.

  • Replication: When flushing tables, there was a slight chance that the flush occurred between the processing of one table map event and the next. Since the tables were opened one by one, subsequent locking of tables would cause the slave to crash. This problem was observed when replicating NDBCLUSTER or InnoDB tables, when executing multi-table updates, and when a trigger or a stored routine performed an (additional) insert on a table so that two tables were effectively being inserted into in the same statement. (Bug#36197)

  • Cluster API: Ordered index scans were not pruned correctly where a partitioning key was specified with an EQ-bound. (Bug#36950)

  • Cluster API: When an insert operation involving BLOB data was attempted on a row which already existed, no duplicate key error was correctly reported and the transaction is incorrectly aborted. In some cases, the existing row could also become corrupted. (Bug#36851)

    See also Bug#26756.

  • Cluster API: NdbApi.hpp depended on ndb_global.h, which was not actually installed, causing the compilation of programs that used NdbApi.hpp to fail. (Bug#35853)