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.
Important Change; Cluster API:
memory page sizes in bytes rather than kilobytes, it has been
page_size_bytes. The name
page_size_kb is now deprecated and thus
subject to removal in a future release, although it currently
remains supported for reasons of backward compatibility. See
Ndb_logevent_type Type, for more information
OPTIMIZE TABLE can now be
interrupted. This can be done, for example, by killing the SQL
thread performing the
Now only 2 local checkpoints are stored, rather than 3 as in previous MySQL Cluster versions. This lowers disk space requirements and reduces the size and number of redo log files needed.
The mysqld option
--ndb-batch-size has been added. This enables
control of the size of batches used for running transactions.
Node recovery can now be done in parallel, rather than sequentially, which can result in much faster recovery times.
NDB tables can now
be controlled using the session variables
NDB tables not to be checkpointed
has the same effect; in addition, when
ndb_table_temporary is used, no
NDB table schema files are created.
ndb_restore now supports basic
attribute promotion; that is, data from a
column of a given type can be restored to a column using a
“larger” type. For example, Cluster backup data
taken from a
SMALLINT column can
be restored to a
For more information, see ndb_restore — Restore a MySQL Cluster Backup.
Important Change; Disk Data:
It is no longer possible on 32-bit systems to issue statements
appearing to create Disk Data log files or data files greater
than 4 GB in size. (Trying to create log files or data files
larger than 4 GB on 32-bit systems led to unrecoverable data
node failures; such statements now fail with
NDB error 1515.)
Replication: The code implementing heartbeats did not check for possible errors in some circumstances; this kept the dump thread hanging while waiting for heartbeats loop even though the slave was no longer connected. (Bug #33332)
High numbers of insert operations, delete operations, or both
NDB error 899
(Rowid already allocated) to occur
A periodic failure to flush the send buffer by the
NDB TCP transporter could cause a
unnecessary delay of 10 ms between operations.
DROP TABLE did not free all data
memory. This bug was observed in MySQL Cluster NDB 6.3.7 only.
A race condition could occur (very rarely) when the release of a GCI was followed by a data node failure. (Bug #33793)
Some tuple scans caused the wrong memory page to be accessed, leading to invalid results. This issue could affect both in-memory and Disk Data tables. (Bug #33739)
A failure to initialize an internal variable led to sporadic crashes during cluster testing. (Bug #33715)
The server failed to reject properly the creation of an
NDB table having an unindexed
The Cluster backup process could not detect when there was no more disk space and instead continued to run until killed manually. Now the backup fails with an appropriate error when disk space is exhausted. (Bug #28647)
It was possible in
config.ini to define
cluster nodes having node IDs greater than the maximum permitted
Under some circumstances, a recovering data node did not use its own data, instead copying data from another node even when this was not required. This in effect bypassed the optimized node recovery protocol and caused recovery times to be unnecessarily long. (Bug #26913)
Consecutive DDL statements involving tables
ALTER TABLE, and
DROP TABLE) could be executed so
quickly that previous DDL statements upon which they depended
were not yet written in the binary log.
For example, if
DROP TABLE foo was issued
CREATE TABLE foo, the
DROP statement could fail because the
CREATE had not yet been recorded.
ndb_restore -e restored excessively large
values to the
epoch column when restoring to a MySQL
Cluster version supporting Micro-GCPs from an older version that
did not support these.
A workaround when restoring to MySQL Cluster releases supporting
micro-GCPs previous to MySQL Cluster NDB 6.3.8 is to perform a
32-bit shift on the
epoch column values to
reduce them to their proper size.
Transactions containing inserts or reads would hang during
made from NDB API applications built against a MySQL Cluster
version that did not support micro-GCPs accessing a later
version that supported micro-GCPs. This issue was observed while
upgrading from MySQL Cluster NDB 6.1.23 to MySQL Cluster NDB
6.2.10 when the API application built against the earlier
version attempted to access a data node already running the
later version, even after disabling micro-GCPs by setting
When reading a
BIT(64) value using
bytes were written to the buffer rather than the expected 8