This is a new Beta development release, fixing recently discovered bugs in previous MySQL Cluster releases.
MySQL Cluster NDB 6.3 no longer in development. MySQL Cluster NDB 6.3 is no longer being actively developed; if you are using a MySQL Cluster NDB 6.3 release, you should upgrade to the latest version of MySQL Cluster, which is available from http://dev.mysql.com/downloads/cluster/ .
Obtaining MySQL Cluster NDB 6.3. This is a source-only release, which you must compile and install using the instructions found in Installing MySQL from Source, and in MySQL Cluster Installation and Upgrades. 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 Changes in MySQL 5.1.23 (2008-01-29)).
Please refer to our bug database at http://bugs.mysql.com/ for more details about the individual bugs fixed in this version.
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
It is now possible to cause statements occurring within the same
transaction to be run as a batch by setting the session variable
To use this feature,
autocommit must be disabled.
Only in-memory tables are supported.
OPTIMIZE still has no effect on Disk Data
Only variable-length columns are supported. However, you can
force columns defined using fixed-length data types to be
dynamic using the
COLUMN_FORMAT option with a
CREATE TABLE or
ALTER TABLE statement.
The performance of
NDB tables can be regulated by
adjusting the value of the
ndb_optimization_delay system variable.
When partition pruning on an
table resulted in an ordered index scan spanning only one
partition, any descending flag for the scan was wrongly
ORDER BY DESC to be
ORDER BY ASC,
MAX() to be handled incorrectly, and similar
When all data and SQL nodes in the cluster were shut down
abnormally (that is, other than by using
in the cluster management client), ndb_mgm
used excessive amounts of CPU.
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
TABLE on an
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
Replication; Cluster Replication:
Where a table being replicated had a
BLOB column, an
UPDATE on the master that did not
refer explicitly to this column in the
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
mysql.ndb_replication table with
the wrong number of columns for the primary key caused
mysqld to crash. Now a
[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