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.34 Changes in MySQL Cluster NDB 6.3.6 (5.1.22-ndb-6.3.6) (08 November 2007)
17.7.3.35 Changes in MySQL Cluster NDB 6.3.5 (5.1.22-ndb-6.3.5) (17 October 2007) »
Section Navigation      [Toggle]

17.7.3.34. Changes in MySQL Cluster NDB 6.3.6 (5.1.22-ndb-6.3.6) (08 November 2007)

This is a new Beta development 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 Beta 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.22 (see Section C.1.30, “Changes in MySQL 5.1.22 (24 September 2007 Release Candidate)”).

Note

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:

  • Important Note: MySQL Cluster NDB 6.2 and 6.3 source archives are now available in separate commercial and GPL versions. Due to licensing concerns, previous MySQL Cluster NDB 6.2 and 6.3 source archives were removed from the FTP site.

  • The output of the ndb_mgm client SHOW and STATUS commands now indicates when the cluster is in single user mode. (Bug#27999)

  • Unnecessary reads when performing a primary key or unique key update have been reduced, and in some cases, eliminated. (It is almost never necessary to read a record prior to an update, the lone exception to this being when a primary key is updated, since this requires a delete followed by an insert, which must be prepared by reading the record.) Depending on the number of primary key and unique key lookups that are performed per transaction, this can yield a considerable improvement in performance.

  • Batched operations are now better supported for DELETE and UPDATE. (UPDATE WHERE... and muliple DELETE.)

  • Introduced the Ndb_execute_count status variable, which measures the number of round trips made by queries to the NDB kernel.

Bugs fixed:

  • An insert or update with combined range and equality constraints failed when run against an NDB table with the error Got unknown error from NDB. An example of such a statement would be UPDATE t1 SET b = 5 WHERE a IN (7,8) OR a >= 10;. (Bug#31874)

  • An error with an if statement in sql/ha_ndbcluster.cc could potentially lead to an infinite loop in case of failure when working with AUTO_INCREMENT columns in NDB tables. (Bug#31810)

  • The NDB storage engine code was not safe for strict-alias optimization in gcc 4.2.1. (Bug#31761)

  • ndb_restore displayed incorrect backup file version information. This meant (for example) that, when attempting to restore a backup made from a MySQL 5.1.22 cluster to a MySQL Cluster NDB 6.3.3 cluster, the restore process failed with the error Restore program older than backup version. Not supported. Use new restore program. (Bug#31723)

  • Following an upgrade, ndb_mgmd would fail with an ArbitrationError. (Bug#31690)

  • The NDB management client command node_id REPORT MEMORY provided no output when node_id was the node ID of a management or API node. Now, when this occurs, the management client responds with Node node_id: is not a data node. (Bug#29485)

  • Performing DELETE operations after a data node had been shut down could lead to inconsistent data following a restart of the node. (Bug#26450)

  • UPDATE IGNORE could sometimes fail on NDB tables due to the use of unitialized data when checking for duplicate keys to be ignored. (Bug#25817)

  • Cluster Replication: Replication: Slave batching did not work correctly with UPDATE statements. (Bug#31787)

  • Cluster Replication: Replication: A node failure during replication could lead to buckets out of order; now active subscribers are checked for, rather than empty buckets. (Bug#31701)

  • Cluster Replication: Updates performed unnecessary writes to the primary keys of the rows being updated. (Bug#31841)

  • Cluster Replication: When the master mysqld crashed or was restarted, no LOST_EVENTS entry was made in the binlog. (Bug#31484)

    See also Bug#21494.