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.33 Changes in MySQL Cluster NDB 6.3.7 (5.1.23-ndb-6.3.7) (19 December 2007)
17.7.3.34 Changes in MySQL Cluster NDB 6.3.6 (5.1.22-ndb-6.3.6) (08 November 2007) »
Section Navigation      [Toggle]

17.7.3.33. Changes in MySQL Cluster NDB 6.3.7 (5.1.23-ndb-6.3.7) (19 December 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.23 (see Section C.1.29, “Changes in MySQL 5.1.23 (29 January 2008)”).

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:

  • Compressed local checkpoints and backups are now supported, resulting in a space savings of 50% or more over uncompressed LCPs and backups. Compression of these can be enabled in the config.ini file using the two new data node configuration parameters CompressedLCP and CompressedBackup, respectively.

  • OPTIMIZE TABLE is now supported for NDBCLUSTER tables, subject to the following limitations:

    • Only in-memory tables are supported. OPTIMIZE still has no effect on Disk Data tables.

    • Only variable-length columns are supported. However, you can force columns defined using fixed-length data types to be dynamic using the ROW_FORMAT or COLUMN_FORMAT option with a CREATE TABLE or ALTER TABLE statement.

    Memory reclaimed from an NDB table using OPTIMIZE is generally available to the cluster, and not confined to the table from which it was recovered, unlike the case with memory freed using DELETE.

    The performance of OPTIMIZE on NDB tables can be regulated by adjusting the value of the ndb_optimization_delay system variable.

  • It is now possible to cause statements occurring within the same transaction to be run as a batch by setting the session variable transaction_allow_batching to 1 or ON.

    Note

    To use this feature, autocommit must be disabled.

Bugs fixed:

  • Partitioning: When partition pruning on an NDB table resulted in an ordered index scan spanning only one partition, any descending flag for the scan was wrongly discarded, causing ORDER BY DESC to be treated as ORDER BY ASC, MAX() to be handled incorrectly, and similar problems. (Bug#33061)

  • When all data and SQL nodes in the cluster were shut down abnormally (that is, other than by using STOP in the cluster management client), ndb_mgm used excessive amounts of CPU. (Bug#33237)

  • When using micro-GCPs, if a node failed while preparing for a global checkpoint, the master node would use the wrong GCI. (Bug#32922)

  • Under some conditions, performing an ALTER TABLE on an NDBCLUSTER table failed with a Table is full error, even when only 25% of DataMemory was in use and the result should have been a table using less memory (for example, changing a VARCHAR(100) column to VARCHAR(80)). (Bug#32670)

  • Cluster Replication: Replication: Where a table being replicated had a TEXT or BLOB column, an UPDATE on the master that did not refer explicitly to this column in the WHERE clause stopped the SQL thread on the slave with Error in Write_rows event: row application failed. Got error 4288 'Blob handle for column not available' from NDBCLUSTER. (Bug#30674)

  • Cluster Replication: Creating the mysql.ndb_replication table with the wrong number of columns for the primary key caused mysqld to crash. Now a CREATE TABLE [mysql.]ndb_replication statement that is invalid for this reason fails with the error Bad schema for mysql.ndb_replication table. Message: Wrong number of primary keys, expected number. (Bug#33159)