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)”).
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
OPTIMIZE TABLE is now supported
NDBCLUSTER tables, subject to
the following limitations:
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.
Memory reclaimed from an
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
The performance of
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
To use this feature,
autocommit must be disabled.
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
Cluster Replication: 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